springframework-developer — Spring Framework developers list

Re: [Springframework-developer] ProxyFactoryBean.getObjectType() behaviour

[Rod J. <rod...@in...>]

Whoops. It looks like it's broken in CVS. It should be
getTargetSource().getTargetClass(), not getTargetSource().getClass().

I'll add some tests and fix it...

Thanks,
Rod

----- Original Message ----- 
From: "roger holbrook" <apo...@sn...>
To: <spr...@li...>
Sent: Monday, December 08, 2003 8:54 AM
Subject: [Springframework-developer] ProxyFactoryBean.getObjectType()
behaviour


> Can anyone explain why the behaviour of this method has changed since the
M2
> release ?
>
> Any clues much appreciated.
>
> Roger
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Re: ProxyFactoryBean.getObjectType() behaviour

[roger h. <apo...@sn...>]

Many thanks

"Rod Johnson" <rod...@in...> wrote in message
news:0cb101c3bd7d$ce0a9eb0$2300a8c0@chopin...
> Roger,
>
> Thanks for the report and proposed fix. I've checked it in. As a bonus,
> ProxyFactoryBean also automatically handles names implementing the new
> BeforeAdvice interface.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "roger holbrook" <apo...@sn...>
> To: <spr...@li...>
> Sent: Monday, December 08, 2003 8:54 AM
> Subject: [Springframework-developer] ProxyFactoryBean.getObjectType()
> behaviour
>
>
> > Can anyone explain why the behaviour of this method has changed since
the
> M2
> > release ?
> >
> > Any clues much appreciated.
> >
> > Roger
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: [Springframework-developer] ProxyFactoryBean.getObjectType() behaviour

[Rod J. <rod...@in...>]

Roger,

Thanks for the report and proposed fix. I've checked it in. As a bonus,
ProxyFactoryBean also automatically handles names implementing the new
BeforeAdvice interface.

Regards,
Rod

----- Original Message ----- 
From: "roger holbrook" <apo...@sn...>
To: <spr...@li...>
Sent: Monday, December 08, 2003 8:54 AM
Subject: [Springframework-developer] ProxyFactoryBean.getObjectType()
behaviour


> Can anyone explain why the behaviour of this method has changed since the
M2
> release ?
>
> Any clues much appreciated.
>
> Roger
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Re: Cflow

[Rod J. <rod...@in...>]

The Java 1.4 version, using Throwable.getStackTrace(), is a bit over twice
as fast as the all-versions code based on parsing the results of
printStackTrace(). It's probably a lot more memory efficient as well.

This begs the question of how we can have both a 1.4 and 1.3 version--any
thoughts on this? The 1.3 version is still fast enough to be viable for
typical usage, so I don't think we can consider this a 1.4-only feature.

Regards,
Rod

----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Sunday, December 07, 2003 2:34 PM
Subject: Re: [Springframework-developer] Re: Cflow


> Chris
>
> At present it parses the stack trace itself, so it works in any version.
> However, the StaceTraceElement stuff from 1.4 may run faster: I'll do a
> benchmark shortly.
>
> If it does run _much_ faster, we might have to consider having different
> versions of that class for each JDK. I guess this is a broader issue
> though--I don't think we want two binary distributions for 1.0.
>
> Overall, Spring doesn't require 1.4 and we have plenty of users on 1.3.
>
> Regards,
> Rod
>
> ----- Original Message ----- 
> From: "Chris Nokleberg" <ch...@si...>
> To: <spr...@li...>
> Sent: Sunday, December 07, 2003 10:51 AM
> Subject: [Springframework-developer] Re: Cflow
>
>
> > Rod Johnson wrote:
> > > I've just checked in a simple "cflow"-style method matcher pointcut,
> that
> > > enables us to apply simple conditions such as "this call came from
> > > com.my.web.MyController class", or perhaps a particular method of such
a
> > > class.
> > >
> > > It's 10-15 times slower to evaluate such a pointcut than a "normal"
> method
> > > matcher, because it's necessary to construct a new Throwable to
analyse
> > > the stack trace (unless someone has a better idea!).
> >
> > There might be a better way if you restrict the cflow matching against
> > classes you can proxy. For example, you could add an around advice to
> every
> > method in com.my.web.MyController. The advice would increment a
> threadlocal
> > before and decrement it after. To check if you're within the cflow you
> just
> > see if the threadlocal value is greater than zero. This is probably more
> > portable too since getStackTrace is 1.4 only (don't know if Spring
> requires
> > 1.4), but then again ThreadLocals are pretty slow on anything below 1.4.
> >
> > Chris
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] ProxyFactoryBean.getObjectType() behaviour

[roger h. <apo...@sn...>]

Can anyone explain why the behaviour of this method has changed since the M2
release ?

Any clues much appreciated.

Roger

Re: [Springframework-developer] Spring Enhancement

[Rod J. <rod...@in...>]

I agree with Peter. So long as the more general solution promises to be
simple, let's at least look at how it pans out. If it turns out that it
needs to be more complex, we can rethink.

Regards,
Rod

----- Original Message ----- 
From: "Peter den Haan" <pe...@de...>
To: <spr...@li...>
Sent: Monday, December 08, 2003 7:43 AM
Subject: Re: [Springframework-developer] Spring Enhancement


> Mike, with all due respect, is it really adding much complexity? More than
> just a small interface, a thin OGNL adapter class and a few lines of
> supporting code? I wasn't necessarily proposing we adopt JEX; frankly, if
> you ask me might not be enough to it to justify another dependency.
>
> In fact, by making the EL pluggable we would create _fewer_ dependencies,
> since you could choose not to plug in OGNL or any other expression
language
> if you didn't want or need it. No such freedom if it'd be hardwired it
into
> the Spring core.
>
>  - Peter
>
>
> ----- Original Message ----- 
> From: "Mike Cannon-Brookes" <mi...@at...>
> To: "Spring" <spr...@li...>
> Sent: Monday, December 08, 2003 12:55 AM
> Subject: Re: [lists] Re: [Springframework-developer] Spring Enhancement
>
>
> > Sorry - but IMHO this is still adding too much complexity for very
little
> > benefit. It adds more dependencies (OGNL is just one JAR) and
> realistically
> > I don't see it being useful. An EL within the context XML file is core
to
> > Spring and shouldn't be pluggable - I vote for simplicity any day :)
> >
> > My $0.02.
> >
> > M
> >
> > On 8/12/03 4:02 AM, "Peter den Haan" (pe...@de...) penned the
> words:
> >
> > > Even if you don't use it as anything other than a source of ideas -- 
are
> you
> > > familiar with JEX (http://www.plotnix.com/jex/)? It's a universal API
> for
> > > expression languages, and it uses precisely this prefix method to
> determine
> > > the language used. Omit the prefix, and you get whatever default
> language
> > > you have configured. JEX expression languages are completely
pluggable.
> > >
> > > IMHO pluggability is very much in line with the Spring philosophy. My
> > > suggestion would be to have a configuration-file level setting for the
> > > default expression language. The default value for this default
language
> > > could, of course, be the trivial expression language that interprets
> > > everything as a literal :)
> > >
> > > I can see some sweet use cases for this -- say, you have an
application
> > > which needs to pull some settings from a user-level XML configuration
> > > file.You could use a FactoryBean to bind the configuration file's DOM
in
> the
> > > application context, pick JXPath as your expression language and use
> XPath
> > > expressions into the configuration file to pull the configuration
values
> > > into your beans...
> > >
> > > - Peter
> > >
> > >
> > > ----- Original Message -----
> > > From: "Colin Sampaleanu" <col...@ex...>
> > > To: <spr...@li...>
> > > Sent: Sunday, December 07, 2003 2:46 PM
> > > Subject: [lists] Re: [Springframework-developer] Spring Enhancement
> > >
> > >
> > >> I think the performance issue is probably not a big deal, as you say.
> > >> W/regards to backwards compatibility though, if strings that were
> > >> previously plaintext in existing elements like <value> were all of a
> > >> sudden interpreted as expressions, at a minimum people would have to
go
> > >> through all the strings and suitably escape any values (like $) that
> > >> would trigger the expression evaluator. What would help in this
respect
> > >> and also on the performance side, is to use a prefix on the string
> value
> > >> to indicate that it's an expression, e.g.
> > >>    ognl:some.expression
> > >> as Tapestry does, for example...
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: IBM Linux Tutorials.
> > > Become an expert in LINUX or just sharpen your skills.  Sign up for
> IBM's
> > > Free Linux Tutorials.  Learn everything from the bash shell to sys
> admin.
> > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Jetty (was Orion 2.0.2)

[Darren D. <dda...@kg...>]

> looks suspiciously like the same problem we saw on Orion.  Using 
> Jetty 
> 4.2.14 and a petclinic deployment..
> 
> 00:55:30.733 WARN!! 
> [Listener-
>
4]org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:592)11>
Exception for / org.apache.jasper.JasperException: /index.jsp(0,0) This
absolute uri 
> (http://www.springframework.org/tags) cannot be resolved in either 
> web.xml or the jar files deployed with this application 	at 
>
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94)
	at
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:428)
... ...
> 
> Tomcat 4.1 and 5.0 are both OK (presumably therefore JBoss/Tomcat 
> will be too).  Anyone tried this on Resin yet?

I've now tried Resin 2.1x and it's OK too.  So Jetty 4.2x is a no-go along
with Orion 2.0x at present.

Regards,

--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] Spring Enhancement

[Peter d. H. <pe...@de...>]

Mike, with all due respect, is it really adding much complexity? More than
just a small interface, a thin OGNL adapter class and a few lines of
supporting code? I wasn't necessarily proposing we adopt JEX; frankly, if
you ask me might not be enough to it to justify another dependency.

In fact, by making the EL pluggable we would create _fewer_ dependencies,
since you could choose not to plug in OGNL or any other expression language
if you didn't want or need it. No such freedom if it'd be hardwired it into
the Spring core.

 - Peter


----- Original Message ----- 
From: "Mike Cannon-Brookes" <mi...@at...>
To: "Spring" <spr...@li...>
Sent: Monday, December 08, 2003 12:55 AM
Subject: Re: [lists] Re: [Springframework-developer] Spring Enhancement


> Sorry - but IMHO this is still adding too much complexity for very little
> benefit. It adds more dependencies (OGNL is just one JAR) and
realistically
> I don't see it being useful. An EL within the context XML file is core to
> Spring and shouldn't be pluggable - I vote for simplicity any day :)
>
> My $0.02.
>
> M
>
> On 8/12/03 4:02 AM, "Peter den Haan" (pe...@de...) penned the
words:
>
> > Even if you don't use it as anything other than a source of ideas -- are
you
> > familiar with JEX (http://www.plotnix.com/jex/)? It's a universal API
for
> > expression languages, and it uses precisely this prefix method to
determine
> > the language used. Omit the prefix, and you get whatever default
language
> > you have configured. JEX expression languages are completely pluggable.
> >
> > IMHO pluggability is very much in line with the Spring philosophy. My
> > suggestion would be to have a configuration-file level setting for the
> > default expression language. The default value for this default language
> > could, of course, be the trivial expression language that interprets
> > everything as a literal :)
> >
> > I can see some sweet use cases for this -- say, you have an application
> > which needs to pull some settings from a user-level XML configuration
> > file.You could use a FactoryBean to bind the configuration file's DOM in
the
> > application context, pick JXPath as your expression language and use
XPath
> > expressions into the configuration file to pull the configuration values
> > into your beans...
> >
> > - Peter
> >
> >
> > ----- Original Message -----
> > From: "Colin Sampaleanu" <col...@ex...>
> > To: <spr...@li...>
> > Sent: Sunday, December 07, 2003 2:46 PM
> > Subject: [lists] Re: [Springframework-developer] Spring Enhancement
> >
> >
> >> I think the performance issue is probably not a big deal, as you say.
> >> W/regards to backwards compatibility though, if strings that were
> >> previously plaintext in existing elements like <value> were all of a
> >> sudden interpreted as expressions, at a minimum people would have to go
> >> through all the strings and suitably escape any values (like $) that
> >> would trigger the expression evaluator. What would help in this respect
> >> and also on the performance side, is to use a prefix on the string
value
> >> to indicate that it's an expression, e.g.
> >>    ognl:some.expression
> >> as Tapestry does, for example...
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Small change made to ContextLoader

[Colin S. <col...@ex...>]

I've modified it to add a template method which may be implemented by a 
subclass to optionally load/initialize an ApplicationContext instance 
which will (if it exists) be used as a parent of the 
WebApplicationContext loaded by ContextLoader.

Re: [Springframework-developer] Passivating statefull session beans

[Colin S. <col...@ex...>]

I've modified the EJB support code to allow a user subclass of 
AbstractStatelessSessionBean to call a new method unloadBeanFactory() 
from ejbPassivate (which it should implement itself). The subclass 
should call the existing loadBeanFactory()  from ejbCreate() and 
ejbActivate().   As well, the default implementation of ejbRemove which 
is in AbstractEnterpriseBean now calls the new unloadBeanFactory() 
method.     There is one change that may affect some existing code, and 
that is that in the process of adding the above, I modified the existing 
BeanFactoryLoader interface to handle unloading as well as loading of a 
beanfactory.

These changes should allow you to use a Stateful Session bean properly 
even  wtih passivation and activation happening.

Regards,
Colin


Tim McAuley wrote:

> Hi,
>
> I've just come across this and believe that some alterations may be 
> needed to the AbstractSessionBean.
>
> We are using JBoss 3.2.1.
>
> When a stateful session bean is passivated in our code the following 
> error appears:
>
> 12:11:39,611 WARN  [AbstractInstanceCache] failed to passivate, 
> id=dnrbujgy-5
> javax.ejb.EJBException: Could not passivate; failed to save state; 
> CausedByExcep
> tion is:
>         org.springframework.beans.factory.xml.XmlBeanFactory
>         at 
> org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivate
> Session(StatefulSessionFilePersistenceManager.java:378)
>         at
>
> We make a call to loadBeanFactory() in ejbCreate() but there does not 
> seem a way to clear the bean factory upon passivation because it is 
> private. It's easy to called loadBeanFactory() once again at 
> ejbActivate() but by that time the damage is done and the bean has 
> probably been removed by the server due to the passivation error.
>
> Any chance you guys could look at this and maybe add in a fix for M4 
> or let me know a suitable work around.
>
> Many thanks,
>
> Tim

Re: [lists] Re: [Springframework-developer] Spring Enhancement

[Mike Cannon-B. <mi...@at...>]

Sorry - but IMHO this is still adding too much complexity for very little
benefit. It adds more dependencies (OGNL is just one JAR) and realistically
I don't see it being useful. An EL within the context XML file is core to
Spring and shouldn't be pluggable - I vote for simplicity any day :)

My $0.02.

M

On 8/12/03 4:02 AM, "Peter den Haan" (pe...@de...) penned the words:

> Even if you don't use it as anything other than a source of ideas -- are you
> familiar with JEX (http://www.plotnix.com/jex/)? It's a universal API for
> expression languages, and it uses precisely this prefix method to determine
> the language used. Omit the prefix, and you get whatever default language
> you have configured. JEX expression languages are completely pluggable.
> 
> IMHO pluggability is very much in line with the Spring philosophy. My
> suggestion would be to have a configuration-file level setting for the
> default expression language. The default value for this default language
> could, of course, be the trivial expression language that interprets
> everything as a literal :)
> 
> I can see some sweet use cases for this -- say, you have an application
> which needs to pull some settings from a user-level XML configuration
> file.You could use a FactoryBean to bind the configuration file's DOM in the
> application context, pick JXPath as your expression language and use XPath
> expressions into the configuration file to pull the configuration values
> into your beans...
> 
> - Peter
> 
> 
> ----- Original Message -----
> From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
> Sent: Sunday, December 07, 2003 2:46 PM
> Subject: [lists] Re: [Springframework-developer] Spring Enhancement
> 
> 
>> I think the performance issue is probably not a big deal, as you say.
>> W/regards to backwards compatibility though, if strings that were
>> previously plaintext in existing elements like <value> were all of a
>> sudden interpreted as expressions, at a minimum people would have to go
>> through all the strings and suitably escape any values (like $) that
>> would trigger the expression evaluator. What would help in this respect
>> and also on the performance side, is to use a prefix on the string value
>> to indicate that it's an expression, e.g.
>>    ognl:some.expression
>> as Tapestry does, for example...
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring Enhancement

[Mike Cannon-B. <mi...@at...>]

But would anyone _actually_ have $ signs in their files? I suppose for
property values they might - I was thinking of bean references. Are $ valid
in bean names?

Not averse to a prefix though - like ognl: - seems simple enough and very
unlikely to create any backwards compatibility problems.

Cheers,
Mike

On 8/12/03 1:46 AM, "Colin Sampaleanu" (col...@ex...) penned the words:

> I think the performance issue is probably not a big deal, as you say.
> W/regards to backwards compatibility though, if strings that were
> previously plaintext in existing elements like <value> were all of a
> sudden interpreted as expressions, at a minimum people would have to go
> through all the strings and suitably escape any values (like $) that
> would trigger the expression evaluator. What would help in this respect
> and also on the performance side, is to use a prefix on the string value
> to indicate that it's an expression, e.g.
>  ognl:some.expression
> as Tapestry does, for example...
> 
> 
> Mike Cannon-Brookes wrote:
> 
>> Colin,
>> 
>> Hrm - I think an expr tag would be a start, but really I don't see why you
>> can't just make everything an expr? I mean - what are the backward
>> compatibility issues?
>> 
>> Or else, have an attribute maybe like type="expr" which indicates the body
>> of the tag is an expression to be evaluated? (The only real need for this I
>> think is in the case of performance parsing the file - but seeing as a
>> context is initialized relatively infrequently, I'm not sure this is such a
>> big issue?) 
>> 
>> Cheers,
>> Mike
>> 
>> On 7/12/03 2:49 AM, "Colin Sampaleanu" (col...@ex...) penned the words:
>> 
>>  
>> 
>>> I was planning to add (optional) OGNL support in about 2-6 weeks
>>> (depending on when we start working on 1.1 features. Now what I was
>>> going to do was a relatively transparent implementation, where a new
>>> <expr> element would be usable anywhere <value> now is, i.e.
>>> 
>>> <property name="whatever">
>>> <expr>ognl:an.ognl.expression</expr>
>>> </property>
>>> 
>>> Allowing usage of expression in existing elements, like <key>, would be
>>> possible, but has some implications in terms of backwards compatibility...
>>> 
>>> 
>>> Mike Cannon-Brookes wrote:
>>> 
>>>    
>>> 
>>>> Or an even better idea... how about supporting OGNL within the Spring
>>>> config
>>>> files? (like Xwork does)
>>>> 
>>>> This would be _awesome_ and I just found a second use case for it (the very
>>>> minute Rob's email came in).
>>>> 
>>>> My use case - Maps.
>>>> 
>>>> The Map syntax is nice, but not very useful in practicality I'm finding as
>>>> the key and value of the map are usually related, for instance I often want
>>>> to put a list of referenced beans into a map, with ref.getName() (or some
>>>> method) called for the key.
>>>> 
>>>> At the moment I have to add a setBeans(List) method to my class, and then
>>>> in
>>>> that setter iterate and add to a map - smelly!
>>>> 
>>>> If we allowed OGNL expressions, it would be very simple to do this in the
>>>> config file itself:
>>>> 
>>>> <property value="myMapProp">
>>>> <map>
>>>>   <entry>
>>>>     <key>$referencedBean.name</key>
>>>>     <value><ref bean="referencedBean" /></value>
>>>>   </entry>
>>>> ... More entries
>>>> </map>
>>>> </property>
>>>> 
>>>> I'm sure there are a million other places where OGNL would be useful too,
>>>> but AFAIK the above can't be done _without_ it?
>>>> 
>>>> Or have I just been at this desk far too long?
>>>> 
>>>> M
>>>> 
>>>> On 2/12/03 8:32 AM, "Rob Butler" (rob...@ve...) penned the
>>>> words:
>>>> 
>>>> 
>>>> 
>>>>      
>>>> 
>>>>> Spring now provides the ability to instantiate an object using either a
>>>>> JavaBean no arg constructor, or any normal Java constructor.  But it does
>>>>> not
>>>>> support calling methods.
>>>>> 
>>>>> Also, Spring requires that a class implement the InitializingBean
>>>>> interface
>>>>> if
>>>>> it needs to perform some "setup" work after the setters have all been
>>>>> called.
>>>>> This means that any class that has this need is tied to the
>>>>> Springframework.
>>>>> 
>>>>> What if the ability to call any arbitrary method was added to Spring?
>>>>> Then
>>>>> users could call "afterPropertiesSet" to do "setup" work without having to
>>>>> implement the InitializingBean interface.  Ideally method calls could be
>>>>> in
>>>>> any order along with calls to setters.  Spring would then call each in
>>>>> order.
>>>>> Thus, allowing some setters to be called, then some methods, then more
>>>>> setters
>>>>> if necessary.  If this is not possible, then methods should be called
>>>>> after
>>>>> setters.
>>>>> 
>>>>> This would allow complete decoupling of classes from Spring.  The
>>>>> InitializingBean & BeanFactoryAware interfaces would no longer be needed
>>>>> (although could remain for backwards compatibility).  This would be very
>>>>> useful when contributing code to other projects that do not want to have a
>>>>> dependency on Spring.  Also, it would allow virtually any class used by
>>>>> /developed for  another IOC framework / lightweight container to be used
>>>>> in
>>>>> Spring.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> Later
>>>>> Rob
>>>>>   
>>>>> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [lists] Re: [Springframework-developer] Spring Enhancement

[Peter d. H. <pe...@de...>]

Even if you don't use it as anything other than a source of ideas -- are you
familiar with JEX (http://www.plotnix.com/jex/)? It's a universal API for
expression languages, and it uses precisely this prefix method to determine
the language used. Omit the prefix, and you get whatever default language
you have configured. JEX expression languages are completely pluggable.

IMHO pluggability is very much in line with the Spring philosophy. My
suggestion would be to have a configuration-file level setting for the
default expression language. The default value for this default language
could, of course, be the trivial expression language that interprets
everything as a literal :)

I can see some sweet use cases for this -- say, you have an application
which needs to pull some settings from a user-level XML configuration
file.You could use a FactoryBean to bind the configuration file's DOM in the
application context, pick JXPath as your expression language and use XPath
expressions into the configuration file to pull the configuration values
into your beans...

 - Peter


----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Sunday, December 07, 2003 2:46 PM
Subject: [lists] Re: [Springframework-developer] Spring Enhancement


> I think the performance issue is probably not a big deal, as you say.
> W/regards to backwards compatibility though, if strings that were
> previously plaintext in existing elements like <value> were all of a
> sudden interpreted as expressions, at a minimum people would have to go
> through all the strings and suitably escape any values (like $) that
> would trigger the expression evaluator. What would help in this respect
> and also on the performance side, is to use a prefix on the string value
> to indicate that it's an expression, e.g.
>    ognl:some.expression
> as Tapestry does, for example...

Re: [Springframework-developer] Spring Enhancement

[Rod J. <rod...@in...>]

+1 

> W/regards to backwards compatibility though, if strings that were 
> previously plaintext in existing elements like <value> were all of a 
> sudden interpreted as expressions, at a minimum people would have to go 
> through all the strings and suitably escape any values (like $) that 
> would trigger the expression evaluator. What would help in this respect 
> and also on the performance side, is to use a prefix on the string value 
> to indicate that it's an expression, e.g.
>    ognl:some.expression
> as Tapestry does, for example...

Re: [Springframework-developer] Spring Enhancement

[Colin S. <col...@ex...>]

I think the performance issue is probably not a big deal, as you say. 
W/regards to backwards compatibility though, if strings that were 
previously plaintext in existing elements like <value> were all of a 
sudden interpreted as expressions, at a minimum people would have to go 
through all the strings and suitably escape any values (like $) that 
would trigger the expression evaluator. What would help in this respect 
and also on the performance side, is to use a prefix on the string value 
to indicate that it's an expression, e.g.
   ognl:some.expression
as Tapestry does, for example...


Mike Cannon-Brookes wrote:

>Colin,
>
>Hrm - I think an expr tag would be a start, but really I don't see why you
>can't just make everything an expr? I mean - what are the backward
>compatibility issues?
>
>Or else, have an attribute maybe like type="expr" which indicates the body
>of the tag is an expression to be evaluated? (The only real need for this I
>think is in the case of performance parsing the file - but seeing as a
>context is initialized relatively infrequently, I'm not sure this is such a
>big issue?) 
>
>Cheers,
>Mike
>
>On 7/12/03 2:49 AM, "Colin Sampaleanu" (col...@ex...) penned the words:
>
>  
>
>>I was planning to add (optional) OGNL support in about 2-6 weeks
>>(depending on when we start working on 1.1 features. Now what I was
>>going to do was a relatively transparent implementation, where a new
>><expr> element would be usable anywhere <value> now is, i.e.
>>
>><property name="whatever">
>><expr>ognl:an.ognl.expression</expr>
>></property>
>>
>>Allowing usage of expression in existing elements, like <key>, would be
>>possible, but has some implications in terms of backwards compatibility...
>>
>>
>>Mike Cannon-Brookes wrote:
>>
>>    
>>
>>>Or an even better idea... how about supporting OGNL within the Spring config
>>>files? (like Xwork does)
>>>
>>>This would be _awesome_ and I just found a second use case for it (the very
>>>minute Rob's email came in).
>>>
>>>My use case - Maps.
>>>
>>>The Map syntax is nice, but not very useful in practicality I'm finding as
>>>the key and value of the map are usually related, for instance I often want
>>>to put a list of referenced beans into a map, with ref.getName() (or some
>>>method) called for the key.
>>>
>>>At the moment I have to add a setBeans(List) method to my class, and then in
>>>that setter iterate and add to a map - smelly!
>>>
>>>If we allowed OGNL expressions, it would be very simple to do this in the
>>>config file itself:
>>>
>>><property value="myMapProp">
>>> <map>
>>>   <entry>
>>>     <key>$referencedBean.name</key>
>>>     <value><ref bean="referencedBean" /></value>
>>>   </entry>
>>>... More entries
>>> </map>
>>></property>
>>>
>>>I'm sure there are a million other places where OGNL would be useful too,
>>>but AFAIK the above can't be done _without_ it?
>>>
>>>Or have I just been at this desk far too long?
>>>
>>>M
>>>
>>>On 2/12/03 8:32 AM, "Rob Butler" (rob...@ve...) penned the
>>>words:
>>>
>>> 
>>>
>>>      
>>>
>>>>Spring now provides the ability to instantiate an object using either a
>>>>JavaBean no arg constructor, or any normal Java constructor.  But it does
>>>>not
>>>>support calling methods.
>>>>
>>>>Also, Spring requires that a class implement the InitializingBean interface
>>>>if
>>>>it needs to perform some "setup" work after the setters have all been
>>>>called.
>>>>This means that any class that has this need is tied to the Springframework.
>>>>
>>>>What if the ability to call any arbitrary method was added to Spring?  Then
>>>>users could call "afterPropertiesSet" to do "setup" work without having to
>>>>implement the InitializingBean interface.  Ideally method calls could be in
>>>>any order along with calls to setters.  Spring would then call each in
>>>>order.
>>>>Thus, allowing some setters to be called, then some methods, then more
>>>>setters
>>>>if necessary.  If this is not possible, then methods should be called after
>>>>setters.
>>>>
>>>>This would allow complete decoupling of classes from Spring.  The
>>>>InitializingBean & BeanFactoryAware interfaces would no longer be needed
>>>>(although could remain for backwards compatibility).  This would be very
>>>>useful when contributing code to other projects that do not want to have a
>>>>dependency on Spring.  Also, it would allow virtually any class used by
>>>>/developed for  another IOC framework / lightweight container to be used in
>>>>Spring.
>>>>
>>>>Thoughts?
>>>>
>>>>Later
>>>>Rob
>>>>   
>>>>

Re: [Springframework-developer] Re: Cflow

[Rod J. <rod...@in...>]

Chris

At present it parses the stack trace itself, so it works in any version.
However, the StaceTraceElement stuff from 1.4 may run faster: I'll do a
benchmark shortly.

If it does run _much_ faster, we might have to consider having different
versions of that class for each JDK. I guess this is a broader issue
though--I don't think we want two binary distributions for 1.0.

Overall, Spring doesn't require 1.4 and we have plenty of users on 1.3.

Regards,
Rod

----- Original Message ----- 
From: "Chris Nokleberg" <ch...@si...>
To: <spr...@li...>
Sent: Sunday, December 07, 2003 10:51 AM
Subject: [Springframework-developer] Re: Cflow


> Rod Johnson wrote:
> > I've just checked in a simple "cflow"-style method matcher pointcut,
that
> > enables us to apply simple conditions such as "this call came from
> > com.my.web.MyController class", or perhaps a particular method of such a
> > class.
> >
> > It's 10-15 times slower to evaluate such a pointcut than a "normal"
method
> > matcher, because it's necessary to construct a new Throwable to analyse
> > the stack trace (unless someone has a better idea!).
>
> There might be a better way if you restrict the cflow matching against
> classes you can proxy. For example, you could add an around advice to
every
> method in com.my.web.MyController. The advice would increment a
threadlocal
> before and decrement it after. To check if you're within the cflow you
just
> see if the threadlocal value is greater than zero. This is probably more
> portable too since getStackTrace is 1.4 only (don't know if Spring
requires
> 1.4), but then again ThreadLocals are pretty slow on anything below 1.4.
>
> Chris
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Cflow

[Chris N. <ch...@si...>]

Rod Johnson wrote:
> I've just checked in a simple "cflow"-style method matcher pointcut, that
> enables us to apply simple conditions such as "this call came from
> com.my.web.MyController class", or perhaps a particular method of such a
> class.
> 
> It's 10-15 times slower to evaluate such a pointcut than a "normal" method
> matcher, because it's necessary to construct a new Throwable to analyse
> the stack trace (unless someone has a better idea!).

There might be a better way if you restrict the cflow matching against
classes you can proxy. For example, you could add an around advice to every
method in com.my.web.MyController. The advice would increment a threadlocal
before and decrement it after. To check if you're within the cflow you just
see if the threadlocal value is greater than zero. This is probably more
portable too since getStackTrace is 1.4 only (don't know if Spring requires
1.4), but then again ThreadLocals are pretty slow on anything below 1.4.

Chris

[Springframework-developer] Cflow

[Rod J. <rod...@in...>]

I've just checked in a simple "cflow"-style method matcher pointcut, that
enables us to apply simple conditions such as "this call came from
com.my.web.MyController class", or perhaps a particular method of such a
class.

It's 10-15 times slower to evaluate such a pointcut than a "normal" method
matcher, because it's necessary to construct a new Throwable to analyse the
stack trace (unless someone has a better idea!).

However, it's still not *that* slow, and the cost wouldn't matter that much
if it were done once per business invocation (my machine can do 4-5K
complete invocations involving such evaluation per second, even running
under a profiler).

The performance issues can also be greatly reduced in composition with other
pointcuts, assuming common sense is used with ordering. So if we want to
advice "setter methods where the call came from wherever" the slow
evaluation happens more rarely.

See org.springframework.aop.support.ControlFlowPointcut.

If you think this functionality is worthwhile, please try it out and--better
still--help to improve it, as I don't have much more time for it. (It's
pretty basic right now.)

Regards,
Rod

Re: [Springframework-developer] weather

[Dmitriy K. <dko...@ru...>]

Correction - 2.5 feet of snow ;-)

Ok, I'm out.

D.

----- Original Message -----
From: Dmitriy Kopylenko <dko...@ru...>
Date: Sunday, December 7, 2003 0:09 am
Subject: Re: [Springframework-developer] weather

> That policy sounds good to me. What everybody thinks?
> 
> Dmitriy.
> 
> P.S.
> Mike thanks - I'm really "enjoying" the snowstorm ;-) 
> In New Jersey it's now 2.5 inches and still snowing :-(
> 
> ----- Original Message -----
> From: Mike Cannon-Brookes <mi...@at...>
> Date: Saturday, December 6, 2003 8:48 pm
> Subject: Re: [Springframework-developer] weather
> 
> > I'm not sure that is the best policy really, it restricts people 
> > from having
> > good ideas.
> > 
> > From my experience using JIRA (!), I'd say the best policy is :
> > 
> > - open the feature suggestions as a free-for-all - anyone can 
> add new
> > feature ideas or improvements.
> > - setup a new mailing list (or just use the CVS list as is done at
> > opensymphony/hibernate etc) and get all 'create issue' messages 
> > sent there
> > so people can sign up to be notified of new issues
> > - aggressively 'manage' your issues in JIRA.
> >   - If you think something is not going to be added, close it as 
> > 'Won'tFix' with a description.
> >   - If you're not sure when to schedule it, create a 'to think 
> about'> version and schedule it there.
> >   - If an issue is a duplicate or contains no extra information, 
> > close it
> > as a dupe and link to the original issue
> > 
> > Any 'unscheduled issue' should be one that noone has looked at, 
> > rather than
> > using 'unscheduled' as a dumping ground for all issues.
> > 
> > My $0.02.
> > 
> > Cheers,
> > Mike
> > 
> > PS The weather in Sydney has been a little up and down, but I 
> hear 
> > next week
> > is going to be a nice sunny beautiful one - enjoy your 
> snowstorms :)
> > 
> > On 7/12/03 5:29 AM, "Dmitriy Kopylenko" (dko...@ru...) 
> > penned the
> > words:
> > 
> > > Yes, but virst we need to discuss what this list is, then add 
> it 
> > to JIRA and
> > > then "vote" for each feature in JIRA. Does it sound good?
> > > 
> > > Dmitriy.
> > > 
> > > ----- Original Message -----
> > > From: Rob Butler <rob...@ve...>
> > > Date: Saturday, December 6, 2003 12:13 pm
> > > Subject: Re: [Springframework-developer] weather
> > > 
> > >> Can anyone add feature suggestions to Jira?
> > >> 
> > >> Western Mass has several inches and more on the way.
> > >> 
> > >> Later
> > >> Rob
> > >> 
> > >> ----- Original Message -----
> > >> From: "Dmitriy Kopylenko" <dko...@ru...>
> > >> To: <spr...@li...>
> > >> Sent: Saturday, December 06, 2003 10:59 AM
> > >> Subject: [Springframework-developer] Spring 1.1 features
> > >> 
> > >> 
> > >>> Everyone,
> > >>> 
> > >>> When we have a list of new features for 1.1, can we put them in
> > >> JIRA?> 
> > >>> Btw, anyone from the North Eastern part of the US? What a 
> weather!> >>> 
> > >>> Regards,
> > >>> Dmitriy.
> > >>> 
> > >>> 
> > >>> 
> > >>> -------------------------------------------------------
> > >>> This SF.net email is sponsored by: IBM Linux Tutorials.
> > >>> Become an expert in LINUX or just sharpen your skills.  Sign up
> > >> for IBM's
> > >>> Free Linux Tutorials.  Learn everything from the bash shell to
> > >> sys admin.
> > >>> Click now! 
> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click> >>> 
> _______________________________________________> >>> 
> Springframework-developer mailing list
> > >>> Spr...@li...
> > >>> https://lists.sourceforge.net/lists/listinfo/springframework-
> > >> developer> 
> > >> 
> > >> 
> > >> -------------------------------------------------------
> > >> This SF.net email is sponsored by: IBM Linux Tutorials.
> > >> Become an expert in LINUX or just sharpen your skills.  Sign up
> > >> for IBM's
> > >> Free Linux Tutorials.  Learn everything from the bash shell 
> to sys
> > >> admin.Click now!
> > >> 
> > >" 
> target="l">http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click_______________________>> ________________________
> > >> Springframework-developer mailing list
> > >> Spr...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/springframework-
> > developer>> 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: IBM Linux Tutorials.
> > > Become an expert in LINUX or just sharpen your skills.  Sign 
> up 
> > for IBM's
> > > Free Linux Tutorials.  Learn everything from the bash shell to 
> > sys admin.
> > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-
> > developer
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up 
> > for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to 
> sys 
> > admin.Click now! 
> > 
> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click_______________________________________________> Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-
> developer> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up 
> for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys 
> admin.Click now! 
> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click_______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] weather

[Dmitriy K. <dko...@ru...>]

That policy sounds good to me. What everybody thinks?

Dmitriy.

P.S.
Mike thanks - I'm really "enjoying" the snowstorm ;-) 
In New Jersey it's now 2.5 inches and still snowing :-(

----- Original Message -----
From: Mike Cannon-Brookes <mi...@at...>
Date: Saturday, December 6, 2003 8:48 pm
Subject: Re: [Springframework-developer] weather

> I'm not sure that is the best policy really, it restricts people 
> from having
> good ideas.
> 
> From my experience using JIRA (!), I'd say the best policy is :
> 
> - open the feature suggestions as a free-for-all - anyone can add new
> feature ideas or improvements.
> - setup a new mailing list (or just use the CVS list as is done at
> opensymphony/hibernate etc) and get all 'create issue' messages 
> sent there
> so people can sign up to be notified of new issues
> - aggressively 'manage' your issues in JIRA.
>   - If you think something is not going to be added, close it as 
> 'Won'tFix' with a description.
>   - If you're not sure when to schedule it, create a 'to think about'
> version and schedule it there.
>   - If an issue is a duplicate or contains no extra information, 
> close it
> as a dupe and link to the original issue
> 
> Any 'unscheduled issue' should be one that noone has looked at, 
> rather than
> using 'unscheduled' as a dumping ground for all issues.
> 
> My $0.02.
> 
> Cheers,
> Mike
> 
> PS The weather in Sydney has been a little up and down, but I hear 
> next week
> is going to be a nice sunny beautiful one - enjoy your snowstorms :)
> 
> On 7/12/03 5:29 AM, "Dmitriy Kopylenko" (dko...@ru...) 
> penned the
> words:
> 
> > Yes, but virst we need to discuss what this list is, then add it 
> to JIRA and
> > then "vote" for each feature in JIRA. Does it sound good?
> > 
> > Dmitriy.
> > 
> > ----- Original Message -----
> > From: Rob Butler <rob...@ve...>
> > Date: Saturday, December 6, 2003 12:13 pm
> > Subject: Re: [Springframework-developer] weather
> > 
> >> Can anyone add feature suggestions to Jira?
> >> 
> >> Western Mass has several inches and more on the way.
> >> 
> >> Later
> >> Rob
> >> 
> >> ----- Original Message -----
> >> From: "Dmitriy Kopylenko" <dko...@ru...>
> >> To: <spr...@li...>
> >> Sent: Saturday, December 06, 2003 10:59 AM
> >> Subject: [Springframework-developer] Spring 1.1 features
> >> 
> >> 
> >>> Everyone,
> >>> 
> >>> When we have a list of new features for 1.1, can we put them in
> >> JIRA?> 
> >>> Btw, anyone from the North Eastern part of the US? What a weather!
> >>> 
> >>> Regards,
> >>> Dmitriy.
> >>> 
> >>> 
> >>> 
> >>> -------------------------------------------------------
> >>> This SF.net email is sponsored by: IBM Linux Tutorials.
> >>> Become an expert in LINUX or just sharpen your skills.  Sign up
> >> for IBM's
> >>> Free Linux Tutorials.  Learn everything from the bash shell to
> >> sys admin.
> >>> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> >>> _______________________________________________
> >>> Springframework-developer mailing list
> >>> Spr...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/springframework-
> >> developer> 
> >> 
> >> 
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: IBM Linux Tutorials.
> >> Become an expert in LINUX or just sharpen your skills.  Sign up
> >> for IBM's
> >> Free Linux Tutorials.  Learn everything from the bash shell to sys
> >> admin.Click now!
> >> 
> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click_______________________>> ________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >> https://lists.sourceforge.net/lists/listinfo/springframework-
> developer>> 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up 
> for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to 
> sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-
> developer
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up 
> for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys 
> admin.Click now! 
> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click_______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] weather

[Mike Cannon-B. <mi...@at...>]

I'm not sure that is the best policy really, it restricts people from having
good ideas.

From my experience using JIRA (!), I'd say the best policy is :

- open the feature suggestions as a free-for-all - anyone can add new
feature ideas or improvements.
- setup a new mailing list (or just use the CVS list as is done at
opensymphony/hibernate etc) and get all 'create issue' messages sent there
so people can sign up to be notified of new issues
- aggressively 'manage' your issues in JIRA.
   - If you think something is not going to be added, close it as 'Won't
Fix' with a description.
   - If you're not sure when to schedule it, create a 'to think about'
version and schedule it there.
   - If an issue is a duplicate or contains no extra information, close it
as a dupe and link to the original issue

Any 'unscheduled issue' should be one that noone has looked at, rather than
using 'unscheduled' as a dumping ground for all issues.

My $0.02.

Cheers,
Mike

PS The weather in Sydney has been a little up and down, but I hear next week
is going to be a nice sunny beautiful one - enjoy your snowstorms :)

On 7/12/03 5:29 AM, "Dmitriy Kopylenko" (dko...@ru...) penned the
words:

> Yes, but virst we need to discuss what this list is, then add it to JIRA and
> then "vote" for each feature in JIRA. Does it sound good?
> 
> Dmitriy.
> 
> ----- Original Message -----
> From: Rob Butler <rob...@ve...>
> Date: Saturday, December 6, 2003 12:13 pm
> Subject: Re: [Springframework-developer] weather
> 
>> Can anyone add feature suggestions to Jira?
>> 
>> Western Mass has several inches and more on the way.
>> 
>> Later
>> Rob
>> 
>> ----- Original Message -----
>> From: "Dmitriy Kopylenko" <dko...@ru...>
>> To: <spr...@li...>
>> Sent: Saturday, December 06, 2003 10:59 AM
>> Subject: [Springframework-developer] Spring 1.1 features
>> 
>> 
>>> Everyone,
>>> 
>>> When we have a list of new features for 1.1, can we put them in
>> JIRA?> 
>>> Btw, anyone from the North Eastern part of the US? What a weather!
>>> 
>>> Regards,
>>> Dmitriy.
>>> 
>>> 
>>> 
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: IBM Linux Tutorials.
>>> Become an expert in LINUX or just sharpen your skills.  Sign up
>> for IBM's
>>> Free Linux Tutorials.  Learn everything from the bash shell to
>> sys admin.
>>> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-
>> developer> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IBM Linux Tutorials.
>> Become an expert in LINUX or just sharpen your skills.  Sign up
>> for IBM's
>> Free Linux Tutorials.  Learn everything from the bash shell to sys
>> admin.Click now!
>> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click_______________________
>> ________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring Enhancement

[Mike Cannon-B. <mi...@at...>]

Colin,

Hrm - I think an expr tag would be a start, but really I don't see why you
can't just make everything an expr? I mean - what are the backward
compatibility issues?

Or else, have an attribute maybe like type="expr" which indicates the body
of the tag is an expression to be evaluated? (The only real need for this I
think is in the case of performance parsing the file - but seeing as a
context is initialized relatively infrequently, I'm not sure this is such a
big issue?) 

Cheers,
Mike

On 7/12/03 2:49 AM, "Colin Sampaleanu" (col...@ex...) penned the words:

> I was planning to add (optional) OGNL support in about 2-6 weeks
> (depending on when we start working on 1.1 features. Now what I was
> going to do was a relatively transparent implementation, where a new
> <expr> element would be usable anywhere <value> now is, i.e.
> 
> <property name="whatever">
> <expr>ognl:an.ognl.expression</expr>
> </property>
> 
> Allowing usage of expression in existing elements, like <key>, would be
> possible, but has some implications in terms of backwards compatibility...
> 
> 
> Mike Cannon-Brookes wrote:
> 
>> Or an even better idea... how about supporting OGNL within the Spring config
>> files? (like Xwork does)
>> 
>> This would be _awesome_ and I just found a second use case for it (the very
>> minute Rob's email came in).
>> 
>> My use case - Maps.
>> 
>> The Map syntax is nice, but not very useful in practicality I'm finding as
>> the key and value of the map are usually related, for instance I often want
>> to put a list of referenced beans into a map, with ref.getName() (or some
>> method) called for the key.
>> 
>> At the moment I have to add a setBeans(List) method to my class, and then in
>> that setter iterate and add to a map - smelly!
>> 
>> If we allowed OGNL expressions, it would be very simple to do this in the
>> config file itself:
>> 
>> <property value="myMapProp">
>>  <map>
>>    <entry>
>>      <key>$referencedBean.name</key>
>>      <value><ref bean="referencedBean" /></value>
>>    </entry>
>> ... More entries
>>  </map>
>> </property>
>> 
>> I'm sure there are a million other places where OGNL would be useful too,
>> but AFAIK the above can't be done _without_ it?
>> 
>> Or have I just been at this desk far too long?
>> 
>> M
>> 
>> On 2/12/03 8:32 AM, "Rob Butler" (rob...@ve...) penned the
>> words:
>> 
>>  
>> 
>>> Spring now provides the ability to instantiate an object using either a
>>> JavaBean no arg constructor, or any normal Java constructor.  But it does
>>> not
>>> support calling methods.
>>> 
>>> Also, Spring requires that a class implement the InitializingBean interface
>>> if
>>> it needs to perform some "setup" work after the setters have all been
>>> called.
>>> This means that any class that has this need is tied to the Springframework.
>>> 
>>> What if the ability to call any arbitrary method was added to Spring?  Then
>>> users could call "afterPropertiesSet" to do "setup" work without having to
>>> implement the InitializingBean interface.  Ideally method calls could be in
>>> any order along with calls to setters.  Spring would then call each in
>>> order.
>>> Thus, allowing some setters to be called, then some methods, then more
>>> setters
>>> if necessary.  If this is not possible, then methods should be called after
>>> setters.
>>> 
>>> This would allow complete decoupling of classes from Spring.  The
>>> InitializingBean & BeanFactoryAware interfaces would no longer be needed
>>> (although could remain for backwards compatibility).  This would be very
>>> useful when contributing code to other projects that do not want to have a
>>> dependency on Spring.  Also, it would allow virtually any class used by
>>> /developed for  another IOC framework / lightweight container to be used in
>>> Spring.
>>> 
>>> Thoughts?
>>> 
>>> Later
>>> Rob
>>>    
>>> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] ProxyFactoryBean fix ?

[roger h. <apo...@sn...>]

Rod

After the recent changes is the following needed for a ProxyFactoryBean
maybe ?

 public Class getObjectType() {
-  return getTargetSource().getClass();
+  return getTargetSource().getTargetClass();
 }

Roger

Re: [Springframework-developer] Spring & JMX

[Ivan R. <iv...@we...>]

Rod Johnson wrote:

> Colin,
> 
> Why don't you check it into the sandbox?
> 
> I've also been thinking about a contrib area...it would be good to have some
> way of sharing code that may or may not ever make it into Spring proper--for
> example, code useful to a lot of users, but not really a part of the
> framework.

   Here's my code (gave me a nice excuse to learn how BeanPostProcessor
   interface works). AbstractJMXBridge is the class to look at. It will
   first try to find a mapping by name, then by class. If that fails it
   will attempt to register the bean directly (that will succeed only if
   the bean implements one of the JMX interfaces).

   MyJMXBridge is an example implementation that uses the MX4J
   MBeanServer.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Spring & JMX

[Mark P. <Mar...@Co...>]

Hi,
We are using the commons-modeler on a current project, no problems as far
as that package is concerned, so I think it would be a good foundation
use.
- Mark

> Colin,
>
> Why don't you check it into the sandbox?
>
> I've also been thinking about a contrib area...it would be good to have
> some
> way of sharing code that may or may not ever make it into Spring
> proper--for
> example, code useful to a lot of users, but not really a part of the
> framework.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
> Sent: Saturday, December 06, 2003 5:35 PM
> Subject: Re: [Springframework-developer] Spring & JMX
>
>
>> I have some code (donated by a friend), which can automatically expose
>> beans in a Spring context via BeanPostProcessor. It's pretty simplistic,
>> but I can also post that here if anybody wants to look at it...
>>
>>
>> Rob Butler wrote:
>>
>> >Looks pretty good initially.  I'll take a better look at the links
>> later
> and
>> >have more feedback then.
>> >
>> >Later
>> >Rob
>> >----- Original Message -----
>> >From: "Ivan Ristic" <iv...@we...>
>> >To: <spr...@li...>
>> >Sent: Saturday, December 06, 2003 12:10 PM
>> >Subject: Re: [Springframework-developer] Spring & JMX
>> >
>> >
>> >
>> >
>> >>>>2) Expose normal beans as JMX MBeans. This would allow any bean to
>> >>>>   be manipulated through the JMX protocol. This is also easy to do
>> >>>>   although there is more work involved.
>> >>>>
>> >>>>
>> >>>Actually, I think this can be a lot less work if done right
>> >>>
>> >>>
>> >>   It is a lot easier than I thought:
>> >>
>> >>   There is an Jakarta Commons package called Modeler
>> >>   (http://jakarta.apache.org/commons/modeler.html) that uses an
>> >>   XML definition file and exposes plain beans as managed beans. This
>> >>   is how it looks like:
>> >>
>> >>-----------------
>> >><mbeans-descriptors>
>> >>
>> >><mbean name="redBean" description="Red Bean" type="Bean">
>> >>     <attribute name="color" description="The color of the bean"
>> >>      type="java.lang.String" />
>> >></mbean>
>> >>
>> >><!-- the same class but expose two attributes instead of one -->
>> >><mbean name="bean" description="Blue Bean" type="Bean">
>> >>     <attribute name="color" description="The color of the bean"
>> >>      type="java.lang.String" />
>> >>
>> >>     <attribute name="name" description="The name of the bean"
>> >>      type="java.lang.String" />
>> >></mbean>
>> >>
>> >></mbeans-descriptors>
>> >>-----------------
>> >>
>> >>   Therefore all one needs to do is:
>> >>
>> >>   1) Prepare an XML definition file specifying for each bean which
>> >>      attributes and methods to expose.
>> >>
>> >>   2) List the beans in an application context, and create
>> >>      managed beans using the definition file.
>> >>
>> >>   Here's a link to the ONLamp article explaining how the
>> >>   Modeler is used:
>> >>
>> >>   http://www.onjava.com/pub/a/onjava/2003/07/09/commons.html
>> >>
>> >>   This Eclipse JMX plugin seems to work all right
>> >>   http://www.xtremej.com/ and you can use it to remotely connect to
>> >>   the exposed beans, get/set attributes and invoke methods.
>> >>
>> >>   Spring could supply an abstract helper class for JMX
>> >>   integration (AbstractJMXBridge). The class would need to be
> subclassed
>> >>   to provide a method to create the JMX-related stuff (create the
>> >>   MBeanServer, and configure it).
>> >>
>> >>   Thoughts?
>> >>
>> >>--
>> >>ModSecurity (http://www.modsecurity.org)
>> >>[ Open source IDS for Web applications ]
>> >>
>> >>
>> >>
>> >>-------------------------------------------------------
>> >>This SF.net email is sponsored by: IBM Linux Tutorials.
>> >>Become an expert in LINUX or just sharpen your skills.  Sign up for
> IBM's
>> >>Free Linux Tutorials.  Learn everything from the bash shell to sys
> admin.
>> >>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>> >>_______________________________________________
>> >>Springframework-developer mailing list
>> >>Spr...@li...
>> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> >>
>> >>
>> >
>> >
>> >
>> >-------------------------------------------------------
>> >This SF.net email is sponsored by: IBM Linux Tutorials.
>> >Become an expert in LINUX or just sharpen your skills.  Sign up for
>> IBM's
>> >Free Linux Tutorials.  Learn everything from the bash shell to sys
>> admin.
>> >Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>> >_______________________________________________
>> >Springframework-developer mailing list
>> >Spr...@li...
>> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> >
>> >
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IBM Linux Tutorials.
>> Become an expert in LINUX or just sharpen your skills.  Sign up for
>> IBM's
>> Free Linux Tutorials.  Learn everything from the bash shell to sys
>> admin.
>> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>