springframework-developer

[Springframework-developer] Spring Enhancement

[Rob B. <rob...@ve...>]

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

[Springframework-developer] Spring Enhancement

[Rob B. <rob...@ve...>]

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] Spring Enhancement

[Daniel P. <po...@ci...>]

I thought about suggesting this a couple of weeks ago when Colin(?)
introduced the MethodInvocationFactoryBean.  I figured it would be shot
down since it basically allows someone to define scripts within a
configuration file...could be extremely useful, but also easily abused.
It would, however, virtually eliminate the need to write custom
FactoryBean implementations to simply adapt the creation of an object to
Spring's requirements for a component.  As an example, we're using
Commons-Digester in an application and we discovered that simply
defining Digesters in our Spring configuration with their relevant rule
sets eliminated the need for custom parses classes.  However, Digester
does not have a setRuleSets() method (have to call addRuleSet() multiple
times for each rule set), so we had to write a custom
DigesterFactoryBean.  Rod's suggestion would allow us to simply
define an addRuleSet method call for each ruleSet.

Consider me in favor of this addition.

Regards,
Daniel

On Mon, Dec 01, 2003 at 07:33:36PM -0500, Rob Butler wrote:
> 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: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring Enhancement

[Rob B. <rob...@ve...>]

> I thought about suggesting this a couple of weeks ago when Colin(?)
> introduced the MethodInvocationFactoryBean.  I figured it would be shot
> down since it basically allows someone to define scripts within a
> configuration file...could be extremely useful, but also easily abused.

I agree it could be abused to perform scripting within the configuration
file.  But if someone wants to abuse Spring (or any framework) they will
always find a way.

Re: [Springframework-developer] Spring Enhancement

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

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: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

OGNL support WAS: [Springframework-developer] Spring Enhancement

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

Any thoughts on this guys? I can't find any replies to it :)

------ Forwarded Message
From: Mike Cannon-Brookes <mi...@at...>
Reply-To: spr...@li...
Date: Tue, 02 Dec 2003 16:02:58 +1100
To: Spring Developer <spr...@li...>
Subject: Re: [Springframework-developer] Spring Enhancement

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: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

------ End of Forwarded Message

RE: OGNL support WAS: [Springframework-developer] Spring Enhancement

[Alef A. \(JTeam\) <al...@jt...>]

Mike,

This was discussed about a month ago shortly (see quoted email below). I
think this is definitely a feature worth while considering! But I don't
think it's possible to include his before 1.0final. We can put it on the
wishlist?

Alef

<QUOTE EMAIL OCTOBER 17TH>
A richer expression language would have its use cases. The right thing
to do might be to make the language pluggable :^)

A little while ago I rolled a simple generic Validator implementation --

configured using the Spring configuration file -- using JEX
(http://www.plotnix.com/jex/). This a little pluggable expression
language framework. I added JEX plugins for regexps and the JSTL
expression language so I could use these (in addition to JavaScript,
BEXL and JXPath) to formulate validation rules. I never fed this back to
the list because the implementation is not quite generic enough (eg
there's no i18n support), but having used it for a while it seems
there's a fair bit of mileage in the idea. A decent expression language
is IMHO exactly what's missing from the
brilliant-idea-but-flawed-execution Struts Validator.

In any case, I can think of a number of reasons why it might be good to
adopt JEX or a Spring equivalent of it.

On a not entirely unrelated note, one of the things I've been missing
from Spring is what you might call "anonymous beans". In some
situations, I don't really want to pollute the namespace with beans that
will only ever be used in one place:

   <bean id="foo" class="eg.Foo">
    <property name="bar"><ref bean="bar"/></property>
   </bean>

   <bean id="bar" class="eg.Bar"/>

But would like to be able to write something like

   <bean id="foo" class="eg.Foo">
    <property name="bar"><bean class="eg.Bar"/></property>
   </bean>

Has this been discussed before?

Spring is the best thing I've come across for a while and I'd love to
contribute something back :^)

 - Peter


----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Wednesday, October 15, 2003 8:17 PM
Subject: [lists] [Springframework-developer] Expression language for use
in ApplicationContext


> Has an expression language available for use in the app context ever 
> been considered? (as per email below)
>
> -------- Original Message --------
> Subject: Re: Spring XMLBeanFactory
> Date: Wed, 15 Oct 2003 15:14:42 -0400
> From: Colin Sampaleanu <col...@ex...>
> To: Vladimir Blagojevic <vla...@cs...>
> References: <Pin...@bl...>
>
>
>
> It can't do this (to the best of my knowledge). There is an expression

> language available for use in the JSP tags, but this is not accessible

> in the contexts.
>
> If there is enough of a use case for this it could certainly be done. 
> One way would be to try leveraging the existing expression language 
> code. I have no idea how easy this would be to do since I've actually 
> never touched the web ui code. Another mechanism would be to bring in 
> something like OGNL, which is quite powerful...
>
> What is your usage scenario?
>
>
> Vladimir Blagojevic wrote:
>
> >Colin,
> >
> >Does XMLBeanFactory support reading property of bean X and assigning 
> >it to bean Y within declarative xml config file? I don't think so, 
> >but is there any chatter on the lists about that?
> >
> >Cheers

</QUOTE EMAIL OCTOBER 17TH>



> -----Oorspronkelijk bericht-----
> Van: spr...@li... 
> [mailto:spr...@li...]
>  Namens Mike Cannon-Brookes
> Verzonden: Wednesday, December 03, 2003 11:04 PM
> Aan: Spring
> Onderwerp: OGNL support WAS: [Springframework-developer] 
> Spring Enhancement
> 
> 
> Any thoughts on this guys? I can't find any replies to it :)
> 
> ------ Forwarded Message
> From: Mike Cannon-Brookes <mi...@at...>
> Reply-To: spr...@li...
> Date: Tue, 02 Dec 2003 16:02:58 +1100
> To: Spring Developer <spr...@li...>
> Subject: Re: [Springframework-developer] Spring Enhancement
> 
> 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: SF.net Giveback Program. Does 
> > SourceForge.net help you be more productive?  Does it help 
> you create 
> > better code?  SHARE THE LOVE, and help us help YOU!  Click Here: 
> > http://sourceforge.net/donate/ 
> > _______________________________________________
> > Springframework-developer mailing list 
> > Spr...@li...
> > 
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> Does SourceForge.net help you be more productive?  Does it 
> help you create better code?  SHARE THE LOVE, and help us 
> help YOU!  Click Here: http://sourceforge.net/donate/ 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> ------ End of Forwarded Message
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN's Audience Survey.
> Help shape OSDN's sites and tell us what you think. Take this 
> five minute survey and you could win a $250 Gift Certificate. 
> http://www.wrgsurveys.com/2003/osdntech03.php?> site=8
> 
> _______________________________________________
> 
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: OGNL support WAS: [Springframework-developer] Spring Enhancement

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

Well, I'm certainly not in favour of making the EL generic or pluggable -
that seems like a world of pain to me. Why do you need a pluggable EL?

However I don't see why dropping in OGNL support should take long - if I get
a chance I might have a hack at it today (never having looked at Spring
internals mind you) to contribute back.

M

On 4/12/03 9:38 AM, "Alef Arendsen (JTeam)" (al...@jt...) penned the
words:

> Mike,
> 
> This was discussed about a month ago shortly (see quoted email below). I
> think this is definitely a feature worth while considering! But I don't
> think it's possible to include his before 1.0final. We can put it on the
> wishlist?
> 
> Alef
> 
> <QUOTE EMAIL OCTOBER 17TH>
> A richer expression language would have its use cases. The right thing
> to do might be to make the language pluggable :^)
> 
> A little while ago I rolled a simple generic Validator implementation --
> 
> configured using the Spring configuration file -- using JEX
> (http://www.plotnix.com/jex/). This a little pluggable expression
> language framework. I added JEX plugins for regexps and the JSTL
> expression language so I could use these (in addition to JavaScript,
> BEXL and JXPath) to formulate validation rules. I never fed this back to
> the list because the implementation is not quite generic enough (eg
> there's no i18n support), but having used it for a while it seems
> there's a fair bit of mileage in the idea. A decent expression language
> is IMHO exactly what's missing from the
> brilliant-idea-but-flawed-execution Struts Validator.
> 
> In any case, I can think of a number of reasons why it might be good to
> adopt JEX or a Spring equivalent of it.
> 
> On a not entirely unrelated note, one of the things I've been missing
> from Spring is what you might call "anonymous beans". In some
> situations, I don't really want to pollute the namespace with beans that
> will only ever be used in one place:
> 
>  <bean id="foo" class="eg.Foo">
>   <property name="bar"><ref bean="bar"/></property>
>  </bean>
> 
>  <bean id="bar" class="eg.Bar"/>
> 
> But would like to be able to write something like
> 
>  <bean id="foo" class="eg.Foo">
>   <property name="bar"><bean class="eg.Bar"/></property>
>  </bean>
> 
> Has this been discussed before?
> 
> Spring is the best thing I've come across for a while and I'd love to
> contribute something back :^)
> 
> - Peter
> 
> 
> ----- Original Message -----
> From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
> Sent: Wednesday, October 15, 2003 8:17 PM
> Subject: [lists] [Springframework-developer] Expression language for use
> in ApplicationContext
> 
> 
>> Has an expression language available for use in the app context ever
>> been considered? (as per email below)
>> 
>> -------- Original Message --------
>> Subject: Re: Spring XMLBeanFactory
>> Date: Wed, 15 Oct 2003 15:14:42 -0400
>> From: Colin Sampaleanu <col...@ex...>
>> To: Vladimir Blagojevic <vla...@cs...>
>> References: <Pin...@bl...>
>> 
>> 
>> 
>> It can't do this (to the best of my knowledge). There is an expression
> 
>> language available for use in the JSP tags, but this is not accessible
> 
>> in the contexts.
>> 
>> If there is enough of a use case for this it could certainly be done.
>> One way would be to try leveraging the existing expression language
>> code. I have no idea how easy this would be to do since I've actually
>> never touched the web ui code. Another mechanism would be to bring in
>> something like OGNL, which is quite powerful...
>> 
>> What is your usage scenario?
>> 
>> 
>> Vladimir Blagojevic wrote:
>> 
>>> Colin,
>>> 
>>> Does XMLBeanFactory support reading property of bean X and assigning
>>> it to bean Y within declarative xml config file? I don't think so,
>>> but is there any chatter on the lists about that?
>>> 
>>> Cheers
> 
> </QUOTE EMAIL OCTOBER 17TH>
> 
> 
> 
>> -----Oorspronkelijk bericht-----
>> Van: spr...@li...
>> [mailto:spr...@li...]
>>  Namens Mike Cannon-Brookes
>> Verzonden: Wednesday, December 03, 2003 11:04 PM
>> Aan: Spring
>> Onderwerp: OGNL support WAS: [Springframework-developer]
>> Spring Enhancement
>> 
>> 
>> Any thoughts on this guys? I can't find any replies to it :)
>> 
>> ------ Forwarded Message
>> From: Mike Cannon-Brookes <mi...@at...>
>> Reply-To: spr...@li...
>> Date: Tue, 02 Dec 2003 16:02:58 +1100
>> To: Spring Developer <spr...@li...>
>> Subject: Re: [Springframework-developer] Spring Enhancement
>> 
>> 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: SF.net Giveback Program. Does
>>> SourceForge.net help you be more productive?  Does it help
>> you create 
>>> better code?  SHARE THE LOVE, and help us help YOU!  Click Here:
>>> http://sourceforge.net/donate/
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> 
>> https://lists.sourceforge.net/lists/listinfo/s>
> pringframework-developer
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us
>> help YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> 
>> ------ End of Forwarded Message
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.net email is sponsored by OSDN's Audience Survey.
>> Help shape OSDN's sites and tell us what you think. Take this
>> five minute survey and you could win a $250 Gift Certificate.
>> http://www.wrgsurveys.com/2003/osdntech03.php?> site=8
>> 
>> _______________________________________________
>> 
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN's Audience Survey.
> Help shape OSDN's sites and tell us what you think. Take this
> five minute survey and you could win a $250 Gift Certificate.
> http://www.wrgsurveys.com/2003/osdntech03.php?site=8
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring Enhancement

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

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] Spring Enhancement

[Alef A. <al...@jt...>]

I've introduced an issue in JIRA for this, though I'd emailed about it
already, but saw just now that I didn't change my smtp-server when
changing from work to home network...

Alef


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Colin Sampaleanu
Sent: Saturday, December 06, 2003 4:50 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring Enhancement


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: [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

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] 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: [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: [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

[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
>

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] 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