springframework-developer — Spring Framework developers list

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
> 

About CGLIB2 (was: RE: [Springframework-developer] Release plan)

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

Juergen (et al),

So the current plan is:

- M4  (CGLIB1): just before X-mas
- RC1 (CGLIB2): 2nd week of January or something.

Is there any idea on when CGLIB2 support is to be introduced (I heard
supporting both of them at a time is a hassle or at least too much
work). We've currently got a project (Spring + Hibernate 2.1) underway
of which a initial release is targetted for the 12th of January.

Are there going to be significant changes when moving from CGLIB1 to 2
(which will force me to stick with M4 for that particular project) or is
it going to be a smooth transition without much impact?

Thanks!

Alef

> -----Oorspronkelijk bericht-----
> Van: spr...@li...=20
> [mailto:spr...@li...]
>  Namens j=FCrgen h=F6ller [werk3AT]
> Verzonden: Tuesday, December 02, 2003 3:27 PM
> Aan: spr...@li...
> Onderwerp: [Springframework-developer] Release plan
>=20
>=20
> Guys,
>=20
> We need to settle on a concrete roadmap.
>=20
> Despite our initial plans to go straight to RC1, I'm inclined=20
> to vote for an M4 in two weeks' time, with the significant=20
> reworkings that have been introduced in the meantime (in the=20
> bean factory and AOP area), with the current state of the=20
> docs, and still with CGLIB1. We can also introduce our=20
> JPetStore version with that release.
>=20
> I suggest to target RC1 for early January then, with CGLIB2=20
> and - most importantly - a proper reference manual. In the=20
> ideal case, 1.0 final could be ready at the end of January.=20
> M4 would correspond to a feature freeze, with full=20
> concentration on bugfixes and docs afterwards. RC1 should=20
> already be as good as it gets, a true "release candidate".
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]
> On Behalf Of Matthew E. Porter
> Sent: Monday, December 01, 2003 6:37 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Hibernate 2.1 and CGLIB
>=20
>=20
> This was a good answer since it provides a roadmap.  Can someone post=20
> this on the wiki or the website for others who may have the same=20
> question?
>=20
>=20
> Cheers,
>    matthew
>=20
> On Dec 1, 2003, at 11:04 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> > Hi Matthew,
> >
> > We've been discussing that for a while. If Hibernate 2.1 gets final
> > early enough (and it seems to, being already in RC1 stage), we will=20
> > switch to it for our 1.0 RCs. If 2.1 would still be far=20
> from final, we=20
> > would probably have to support both CGLIB1 and CGLIB2 somehow.=20
> > Fortunately, that seems not to be necessary anymore!
> >
> > For the time being, if you don't proxy full classes (but just
> > interfaces) or don't use Spring AOP in the first place, you=20
> should be=20
> > able to work with Hibernate 2.1 and its CGLIB2 without hassle. The=20
> > same will apply to Hibernate 2.0 users after we've moved to CGLIB2:=20
> > You don't need to worry if you don't use Spring AOP will=20
> full proxies.
> >
> > I think we can live with requiring an update to Hibernate 2.1 if a
> > user wants full AOP proxies in combination. Actually, we probably=20
> > *need* to move to CGLIB2 once Hibernate 2.1 final is=20
> released: Power=20
> > users will want to combine full Spring AOP proxying with=20
> the current=20
> > Hibernate version, not with a previous one.
> >
> > Now it would be really great if CGLIB2 were final too until=20
> Spring 1.0
> > final! :-) It's no problem to ship a CGLIB2 beta with our upcoming=20
> > Spring 1.0 RC1, but it worries me to include a CGLIB2 beta=20
> in Spring=20
> > 1.0 final. Haven't the Hibernate guys the same problem? Or are they=20
> > fine with shipping a CGLIB2 beta with Hibernate 2.1 final?
> >
> > So I suggest to release our 1.0 RC1 shortly after Hibernate=20
> 2.1 final,
> > already with CGLIB2 support. As I said, we will just force=20
> users with=20
> > full AOP proxies to upgrade to Hibernate 2.1 if using the two in=20
> > combination. We could release a 1.0 M4 shortly before that though,=20
> > still with CGLIB1 - to ease migration paths for Hibernate 2.0 users.
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On=20
> > Behalf Of Matthew E. Porter
> > Sent: Monday, December 01, 2003 5:06 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] Hibernate 2.1 and CGLIB
> >
> >
> > I have looked through the mailing list archives but was=20
> unable to find=20
> > the answer to my question.  Will Spring move to support=20
> Hibernate 2.1=20
> > (as it is the new *recommended* version) and, if so, when?
> >
> > Also, does anyone know if I can use it now with the cglib version=20
> > change?
> >
> >
> >
> > Cheers,
> >    matthew
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program. Does=20
> > SourceForge.net help you be more productive?  Does it help=20
> you create=20
> > better code?  SHARE THE LOVE, and help us help YOU!  Click Here:=20
> > http://sourceforge.net/donate/=20
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-developer
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program. Does=20
> > SourceForge.net help you be more productive?  Does it help=20
> you create=20
> > better code?  SHARE THE LOVE, and help us help YOU!  Click Here:=20
> > http://sourceforge.net/donate/=20
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive?  Does it=20
> help you create better code?  SHARE THE LOVE, and help us=20
> help YOU!  Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive?  Does it=20
> help you create better code?  SHARE THE LOVE, and help us=20
> help YOU!  Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

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: [Springframework-developer] FW: [springframework - Help] AOP interception of FactoryBean components?

[<jue...@we...>]

PropertyValuesProviderFactoryBean is already dissolved :-)

I think the simplest way to optionally apply BeanPostProcessors to =
FactoryBean-created objects is to place the burden on the FactoryBean =
implementation: It is the one that knows when the objects actually get =
created and need BeanPostProcessors invoked on them.

I've just introduced a "applyBeanPostProcessors(existingBean,name)" =
method to the BeanFactory interface, accompanying the recently added =
"autowireExistingBean(existingBean,autowireMode,dependencyCheck)" =
method. A FactoryBean can implement BeanFactoryAware and invoke =
applyBeanPostProcessors for a given object whenever it feels the need =
to.=20

If a FactoryBean wants to pass its bean definition name to =
BeanPostProcessors invoked on its created object, it can additionally =
implement BeanNameAware, using that name for applyBeanPostProcessors =
invocations.

The alternative would be to place the burden on the BeanFactory =
implementation, requiring special means to check that BeanPostProcessors =
are just invoked once for any Factory-Bean created object. And that =
would require a new XML bean definition attribute too, just applicable =
to FactoryBeans, or a new method in the FactoryBean interface.

As custom BeanPostProcessors are a rather rare requirement anyway, I =
guess the programmatic solution should be sufficient. There's nothing a =
BeanPostProcessor can do that you couldn't to with a custom FactoryBean =
implementation, or an additional FactoryBean that fronts your existing =
FactoryBean. Invoke the new applyBeanPostProcessors there if you need =
to.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Wednesday, December 03, 2003 1:33 PM
To: spr...@li...
Subject: Re: [Springframework-developer] FW: [springframework - Help]
AOP interception of FactoryBean components?


>Of course, a defined ProxyFactoryBean with a custom FactoryBean as =
target
would proxy the created object, as expected. But as Daniel noted, an =
auto
proxy creator would currently get applied to the FactoryBean instead of =
the
created object.
>Should we leave it that way? Bean properties, lifecycle methods, and =
also
bean post processors like ApplicationContextAwareProcessor are in fact =
meant
to be applied on the FactoryBean itself. Could we add a clean option to
apply bean post processors to the created objects, if demanded?

I think we should leave it that way by default, and perhaps add an
alternative option to post process created objects.

>BTW, I think that our current PropertyValuesProviderFactoryBean
sub-interface is useless. All the bean factory does with the =
PropertyValues
from there is to apply them to the created object via a newly =
instantiated
BeanWrapper: A FactoryBean implementation could easily do that itself =
with a
one-liner, if actually required.

Good point. Get rid of it if you like.

Regards,
Rod




-------------------------------------------------------
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=3D8
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring & JMX

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

Rob Butler wrote:

>>There are some similarities between JMX and Spring. The JMX spec.
>>defines a MLET service, a class capable of loading JMX components
>>(MBean) based on the XML-like file format.
> 
> The XML format is usually too different between different JMX Kernel
 > implementations to get any sort of portability at all.

   Is it? Because MLET is part of the standard spec. But that's
   not important as MLET is not good enough anyway.


>>I have always thought that Spring could play well with JMX, creating
>>MBeans in the same manner as it creates "plain" beans. There are two
>>things to do:
>>
>>1) Detect beans that are also mbeans and register them with the
>>    MBeanServer. This should be very easy to do. Spring already
>>    supports bean initialization, we have a name - there is only
>>    call to mserver instance missing. Of course, there are more
>>    complex things to deal with but not much.
> 
> 
> Only if you have to do something special..  There is actually a
 > much better way in my opinion -- see below.

   I agree what you've said below but you still need to support
   static mbeans. It would make no sense to have to supply additional
   configuration for a static mbean :)



>>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, and
 > provide portability too.

   Yes, that is great. The only drawback would be that it will
   complicate the configuration file further. Perhaps Spring should
   support another configuration file with a different syntax. And
   this configuration file would use bean names to reference beans and
   then specify which attributes and methods should be exposed to JMX.


> Hope this helps out.  When I get some spare time I hope to do a lot
 > of these things with Spring - and contribute some patches too.  But
> that is going to have to wait a little while. :(

   Same here. Actually I am just starting with an JMX project but
   I think I will use the MX4J syntax for the time being (I don't need
   JMX implementation portability). I am on a tight deadline.


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

Re: [Springframework-developer] Spring & JMX

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

> 
> There are some similarities between JMX and Spring. The JMX spec.
> defines a MLET service, a class capable of loading JMX components
> (MBean) based on the XML-like file format.

The XML format is usually too different between different JMX Kernel implementations to get any sort of portability at all.  This is bad if you are building something you want to deploy in multiple locations (like JBoss & Websphere 5.0) because you would have to maintain a different XML file for each.

> I have always thought that Spring could play well with JMX, creating
> MBeans in the same manner as it creates "plain" beans. There are two
> things to do:
> 
> 1) Detect beans that are also mbeans and register them with the
>     MBeanServer. This should be very easy to do. Spring already
>     supports bean initialization, we have a name - there is only
>     call to mserver instance missing. Of course, there are more
>     complex things to deal with but not much.

Only if you have to do something special..  There is actually a much better way in my opinion -- see below.

> 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, and provide portability too.  The JMX spec requires a JMX kernel to provide a "model" mbean - the RequiredModelMBean.  The RequiredModelMBean has a no-arg constructor (RequiredModelMBean()) and also has JavaBean style setters for most pieces of the required data.  (Does Spring support passing two fields to a setter?) Also since Spring supports constructors now you should be able to "construct" a ModelMBean using only Spring.  OR, if Spring cannot currently do this directly (because it cannot pass two fields to a setter) building a generic Spring ModelMBean factory shouldn't be too tough.  Then this ModelMBean factory could be used to construct any ModelMBean you need.  

ModelMBeans are pretty cool because you can have them invoke arbitrary getters / setters / functions on your java code.  So once the Generic ModelMBean factory is built (if it even has to be) you can use it to "construct" a JMX MBean at startup using Spring, and have this MBean invoke operations on your standard javabeans.  This allows you to pretty much expose any operation or property of your beans via JMX without having to write new code.  Additional JMX MBeans or capabilities is as easy as changing your spring config.  Also, since the RequiredModelMBean is available in EVERY JMX kernel, and it's API is set by the JMX spec, you have true portability.  Not bad eh.

I haven't done this yet, but it is how I thought the problem could be approached.  Now to complete the circle all you need is to persist the modifications your JMX calls make.  Thus the suggestions I made earlier on the list about storing configuration in a database, and then having Spring reload. (see the archives)  Then instead of having the JMX ModelMBean invoke operations on the setters, you have it invoke operations on the DB via DAO.  Then reload spring and all changes take effect.  (of course your app has to be designed to support reload).  You can still "wire up" your javabeans to obtain read only performance type information.  Springs support for events in the application context would be helpful here.  (P.S. Spring needs more work in the event handling area to be more robust - threading issues are pretty much ignored in the current implementation.)

Hope this helps out.  When I get some spare time I hope to do a lot of these things with Spring - and contribute some patches too.  But that is going to have to wait a little while. :(

Later
Rob

[Springframework-developer] Passivating statefull session beans

[Tim M. <tec...@mo...>]

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

[Springframework-developer] Spring & JMX

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

There are some similarities between JMX and Spring. The JMX spec.
defines a MLET service, a class capable of loading JMX components
(MBean) based on the XML-like file format.

MX4J 2.0, an open source implementation, takes this one step
further (because the file format from the specification is in many
ways inadequate). Its configuration file looks like this:

-------------------------------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<configuration>
    <startup>
       <create classname="mx4j.tools.adaptor.http.HttpAdaptor" 
objectname="connectors:type=http" loadername="null">
          <arg type="int">9090</arg>
          <arg type="string">localhost</arg>
       </create>
       <create classname="mx4j.tools.adaptor.http.XSLTProcessor" 
objectname="connectors:type=http,processor=xslt" loadername="null"/>
       <call objectname="connectors:type=http" 
attribute="ProcessorNameString">
          <arg type="string">connectors:type=http,processor=xslt</arg>
       </call>
       <call objectname="connectors:type=http" operation="start"/>
    </startup>

    <shutdown>
       <call objectname="connectors:type=http" operation="stop"/>
    </shutdown>
</configuration>
-------------------------------------------

I have always thought that Spring could play well with JMX, creating
MBeans in the same manner as it creates "plain" beans. There are two
things to do:

1) Detect beans that are also mbeans and register them with the
    MBeanServer. This should be very easy to do. Spring already
    supports bean initialization, we have a name - there is only
    call to mserver instance missing. Of course, there are more
    complex things to deal with but not much.

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.

Any opinions on this?

...

Slightly off-topic to this email but related to another email thread,
you can see how MX4J supports a <call> tag to execute methods on
instantiated beans. Maybe that would be an interesting addition to
the container capabilities of the Spring framework now.

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

Re: [Springframework-developer] Re: Release plan

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

> I must say that as I am trying to get the overall "big picture", reading
> the API doc for every class has become quite teadious.
>
> OT: Would getting the book "Expert One-on-One: J2EE Design and
> Development" give me a better overall insight into Spring? It is my
> understanding that Rod essentially outlined the Spring framework in that
> book.

Yes, it will certainly help with the big picture. For example, it outlines
the IoC approach and the rationale behind it, and the essentials of the JDBC
package and web framework. And it's a good book anyway :-)

The picture has gotten bigger since the book was published, however. New
features include AOP and transaction management.

Regards,
Rod

Re: [Springframework-developer] Re: Release plan

[Patrick B. <spr...@pa...>]

Chris Nokleberg wrote:

> jürgen höller [werk3AT] wrote:
> 
>>Despite our initial plans to go straight to RC1, I'm inclined to vote for
>>an M4 in two weeks' time, with the significant reworkings that have been
>>introduced in the meantime (in the bean factory and AOP area), with the
>>current state of the docs, and still with CGLIB1. We can also introduce
>>our JPetStore version with that release.
> 
> 
> FWIW don't quote me on this but I think it's likely that Hibernate 2.1 final
> will be released before M4.
> 
> Chris

I must say that as I am trying to get the overall "big picture", reading 
the API doc for every class has become quite teadious.

OT: Would getting the book "Expert One-on-One: J2EE Design and 
Development" give me a better overall insight into Spring? It is my 
understanding that Rod essentially outlined the Spring framework in that 
book.

Thanks,
Patrick

Re: [Springframework-developer] FW: [springframework - Help] AOP interception of FactoryBean components?

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

>Of course, a defined ProxyFactoryBean with a custom FactoryBean as target
would proxy the created object, as expected. But as Daniel noted, an auto
proxy creator would currently get applied to the FactoryBean instead of the
created object.
>Should we leave it that way? Bean properties, lifecycle methods, and also
bean post processors like ApplicationContextAwareProcessor are in fact meant
to be applied on the FactoryBean itself. Could we add a clean option to
apply bean post processors to the created objects, if demanded?

I think we should leave it that way by default, and perhaps add an
alternative option to post process created objects.

>BTW, I think that our current PropertyValuesProviderFactoryBean
sub-interface is useless. All the bean factory does with the PropertyValues
from there is to apply them to the created object via a newly instantiated
BeanWrapper: A FactoryBean implementation could easily do that itself with a
one-liner, if actually required.

Good point. Get rid of it if you like.

Regards,
Rod

[Springframework-developer] FW: [springframework - Help] AOP interception of FactoryBean components?

[<jue...@we...>]

Actually, that's *not* easy to address: Currently, the bean factory just =
processes the FactoryBean itself, in terms of bean properties, lifecycle =
methods, and bean post processors. The created object is completely the =
responsibility of the FactoryBean.

Of course, a defined ProxyFactoryBean with a custom FactoryBean as =
target would proxy the created object, as expected. But as Daniel noted, =
an auto proxy creator would currently get applied to the FactoryBean =
instead of the created object.

Should we leave it that way? Bean properties, lifecycle methods, and =
also bean post processors like ApplicationContextAwareProcessor are in =
fact meant to be applied on the FactoryBean itself. Could we add a clean =
option to apply bean post processors to the created objects, if =
demanded?

BTW, I think that our current PropertyValuesProviderFactoryBean =
sub-interface is useless. All the bean factory does with the =
PropertyValues from there is to apply them to the created object via a =
newly instantiated BeanWrapper: A FactoryBean implementation could =
easily do that itself with a one-liner, if actually required.

And currently, the bean factory applies such property values on every =
FactoryBean.getObject call, be it for a singleton object or not. It =
would need to apply them once to a singleton object, via storing where =
already applied - but I prefer getting rid of =
PropertyValuesProviderFactoryBean in the first place.

Juergen


-----Original Message-----
From: SourceForge.net [mailto:no...@so...]
Sent: Tuesday, December 02, 2003 11:08 PM
To: no...@so...
Subject: [springframework - Help] AOP interception of FactoryBean
components?



Read and respond to this message at:=20
https://sourceforge.net/forum/message.php?msg_id=3D2314648
By: djpotter77

How might one go about defining an interceptor for a component created =
by a
FactoryBean (not the FactoryBean itself)?  Providing the bean id of the =
component
to an auto proxy creator simply causes the getObject() and isSingleton() =
methods
of the underlying FactoryBean to be intercepted, not the component =
you're really
interested in intercepting.

Regards,
Daniel



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:=20
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250340

[Springframework-developer] FileSystemXmlApplicationContext

[Andreas R. <and...@ya...>]

Hello,

note to org.springframework.context.support.FileSystemXmlApplicationContext

Is it possible to extend the method loadBeanDefinitions
like the attached patch?

I would like to see the filename which contain the error. J=FCrgen?

Best regards
		Andy

=2D-=20
Andreas Rudolf
Im Wiesengrund 27
53560 Vettelscho=DF
Tel: 02645 972965
E-Mail: and...@ya...

[Springframework-developer] Hibernate 2.1rc1 Changes Affects Spring Frameworks

[news.gmane.org <ck...@id...>]

Hi,

I am wondering if it is possible to update LocalSessionFactoryBean to work
with the new changes in Hibernate 2.1rc1's Configuration class.

The following change would be great for LocalSessionFactoryBean if possible:

config.addJar(String resource) is now deprecated in favor of
config.addJar(File jar). No need to remove the current support for the
config.addJar(String) as I am sure there are still others using older
hibernate versions, but perhaps add in additional code to work with the new
addJar(File).  Maybe jarFileResource or something.  And the file resource
will look in a directory relative to some root (ie. WEB-INF/) that can be
specified.


Is that perhaps workable?

Thanks,
Chris

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

[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] DataBinder.getBeanWrapper gone...

[<jue...@we...>]

It's OK for me to change it to public. That indeed makes sense now that =
the DataBinders just contain a BindException instead of deriving from =
it.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Alef Arendsen (JTeam)
Gesendet: Di 02.12.2003 22:20
An: spr...@li...
Betreff: [Springframework-developer] DataBinder.getBeanWrapper gone...



Juergen,=20

I saw you changed the DataBinder to make it contain the BindException =
instead of extending it. I used to (and still) extend the DataBinder =
sometimes to get advanced behavior for for instance ListDataBinders. In =
those extension I usually need the beanwrapper to be able to replace the =
instance wrapped by the bean (using getBeanWrapper.setWrappedInstance()  =
  ).

Since this method - BindException.getBeanWrapper() - is protected and =
the databinder does not extend is anymore, can we make this public?

Alef=20


=3D=3D=20
JTeam B.V.=20
Donker Curtiusstraat 7-412=20
1051 JL  Amsterdam=20
T: +31 20 486 20 36=20
M: +31 6 24 11 1996=20
F: +31 84 837 00 00=20
E: al...@jt...=20
W: http://www.jteam.nl <http://www.jteam.nl> =20

[Springframework-developer] DataBinder.getBeanWrapper gone...

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

Juergen,

I saw you changed the DataBinder to make it contain the BindException
instead of extending it. I used to (and still) extend the DataBinder
sometimes to get advanced behavior for for instance ListDataBinders. In
those extension I usually need the beanwrapper to be able to replace the
instance wrapped by the bean (using getBeanWrapper.setWrappedInstance()
).

Since this method - BindException.getBeanWrapper() - is protected and
the databinder does not extend is anymore, can we make this public?

Alef


==
JTeam B.V.
Donker Curtiusstraat 7-412
1051 JL  Amsterdam
T: +31 20 486 20 36
M: +31 6 24 11 1996
F: +31 84 837 00 00
E: al...@jt...
W: http://www.jteam.nl

[Springframework-developer] Re: Further AOP refactoring

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

Rod Johnson wrote:
> "CGLIB subclass optimizations" mean that methods with no advice aren't
> overridden. This gives a 2x performance boost for non-advised methods
> (excluding the work of the method, which may of course be more
> significant). However, there are some tradeoffs to be aware of in certain
> cases:
> 
> - To do this, the original target is copied fieldwise into the instance of
> the enhanced class. This means  that the original class must have a no-arg
> constructor. Also if the old target was registered as a listener for other
> objects, the new class won't be.
> - This doesn't work with pooling, thread local or other "dynamic"
> TargetSources: only for a single shared instance
> - It's impossible to change the target or TargetSource or advice
> thereafter.

Given these constraints, the CGLIB2 option ("option #1") of using a "shell"
proxy and dispatching back to the original bean seems like the way to go.
By using the Dispatcher instead of LazyLoader you can make the proxy work
for dynamic target sources with only a slight performance hit. Plus you do
not need to do the fieldwise copying. I believe the performance would be
similar to OptimizedCglib1AopProxy but should work for *any* bean. When you
switch to CGLIB2 I'll put together an example patch.

BTW in all cases you could use CGLIB2 to optimize away the check against
EQUALS_METHOD and Advised.class by shunting them to their own interceptors
using a CallbackFilter.

Chris

[Springframework-developer] Re: Release plan

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

jürgen höller [werk3AT] wrote:
> Despite our initial plans to go straight to RC1, I'm inclined to vote for
> an M4 in two weeks' time, with the significant reworkings that have been
> introduced in the meantime (in the bean factory and AOP area), with the
> current state of the docs, and still with CGLIB1. We can also introduce
> our JPetStore version with that release.

FWIW don't quote me on this but I think it's likely that Hibernate 2.1 final
will be released before M4.

Chris

Re: [Springframework-developer] Spring Enhancement

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

Looks like my message got posted to the list twice...  Sorry!

Later
Rob

Re: [Springframework-developer] Release plan

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

> Despite our initial plans to go straight to RC1, I'm inclined to 
> vote for an M4 in two weeks' time, with the significant reworkings 
> that have been introduced in the meantime (in the bean factory and 
> AOP area), with the current state of the docs, and still with 
> CGLIB1. We can also introduce our JPetStore version with that release.

+1

The docs issue is important - other developers here that are evaluating Spring
continually cite this as a problem.

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

RE: [Springframework-developer] Release plan

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

+1 for M4

> Does anybody see a problem=20
> with some of the JavaDoc text=20
> beeing repeated in the reference doc?
Not really, as long as we're not going to end up with a reference doc
that is describing each and every class in detail, without giving
insight in the general picture and provide examples, but I think that's
not the problem...

Alef

> -----Oorspronkelijk bericht-----
> Van: spr...@li...=20
> [mailto:spr...@li...]
>  Namens tri...@tr...
> Verzonden: Tuesday, December 02, 2003 4:10 PM
> Aan: spr...@li...
> Onderwerp: RE: [Springframework-developer] Release plan
>=20
>=20
> +1 for M4 - this will get the latest StoredProcedure with Mapped=20
> +ResultSet
> implementation into a release quicker.  The original version=20
> using a RowCallbackHandler was not that useful since there=20
> was nowhere to put the results in a thread safe manner.
>=20
> For the documentation, I'm approaching this the following way:
>=20
> 1. Create anoutline based on the central concepts and most=20
> frequently used features. 2. Fill in the outline with the=20
> JavaDoc text from the corresponding classes. 3. Enhance the=20
> text a bit. 4. Add codesamples where necessary.
>=20
> At this point we should have a decent document
>=20
> 5. Repeat 3 and 4 until perfect :-)
>=20
> Does anybody see a problem with some of the JavaDoc text=20
> beeing repeated in the reference doc?
>=20
> Thomas
>=20
> Quoting "Kopylenko, Dmitry" <dko...@ac...>:
>=20
> > +1 for M4. I would agree that the docs should be in "good shape" by=20
> > +the time
> > of RC and final.
> >=20
> > Dmitriy.
> >=20
> > -----Original Message-----
> > From: j=FCrgen h=F6ller [werk3AT] =
[mailto:jue...@we...]
> > Sent: Tuesday, December 02, 2003 9:27 AM
> > To: spr...@li...
> > Subject: [Springframework-developer] Release plan
> >=20
> >=20
> > Guys,
> >=20
> > We need to settle on a concrete roadmap.
> >=20
> > Despite our initial plans to go straight to RC1, I'm=20
> inclined to vote=20
> > for an M4 in two weeks' time, with the significant reworkings that=20
> > have been introduced in the meantime (in the bean factory and AOP=20
> > area), with the current state of the docs, and still with=20
> CGLIB1. We=20
> > can also introduce our JPetStore version with that release.
> >=20
> > I suggest to target RC1 for early January then, with CGLIB2=20
> and - most=20
> > importantly - a proper reference manual. In the ideal case,=20
> 1.0 final=20
> > could be ready at the end of January. M4 would correspond=20
> to a feature=20
> > freeze, with full concentration on bugfixes and docs=20
> afterwards. RC1=20
> > should already be as good as it gets, a true "release candidate".
> >=20
> > Juergen
> >=20
> >=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On=20
> > Behalf Of Matthew E. Porter
> > Sent: Monday, December 01, 2003 6:37 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] Hibernate 2.1 and CGLIB
> >=20
> >=20
> > This was a good answer since it provides a roadmap.  Can=20
> someone post
> > this on the wiki or the website for others who may have the same=20
> > question?
> >=20
> >=20
> > Cheers,
> >    matthew
> >=20
> > On Dec 1, 2003, at 11:04 AM, j=FCrgen h=F6ller [werk3AT] wrote:
> >=20
> > > Hi Matthew,
> > >
> > > We've been discussing that for a while. If Hibernate 2.1=20
> gets final=20
> > > early enough (and it seems to, being already in RC1=20
> stage), we will=20
> > > switch to it for our 1.0 RCs. If 2.1 would still be far=20
> from final,=20
> > > we would probably have to support both CGLIB1 and CGLIB2 somehow.=20
> > > Fortunately, that seems not to be necessary anymore!
> > >
> > > For the time being, if you don't proxy full classes (but just
> > > interfaces) or don't use Spring AOP in the first place,=20
> you should=20
> > > be
> > > able to work with Hibernate 2.1 and its CGLIB2 without=20
> hassle. The=20
> > > same will apply to Hibernate 2.0 users after we've moved=20
> to CGLIB2:=20
> > > You don't need to worry if you don't use Spring AOP will=20
> full proxies.
> > >
> > > I think we can live with requiring an update to Hibernate=20
> 2.1 if a=20
> > > user wants full AOP proxies in combination. Actually, we probably
> > > *need* to move to CGLIB2 once Hibernate 2.1 final is=20
> released: Power
> > > users will want to combine full Spring AOP proxying with=20
> the current=20
> > > Hibernate version, not with a previous one.
> > >
> > > Now it would be really great if CGLIB2 were final too=20
> until Spring=20
> > > 1.0 final! :-) It's no problem to ship a CGLIB2 beta with our=20
> > > upcoming Spring 1.0 RC1, but it worries me to include a=20
> CGLIB2 beta=20
> > > in Spring 1.0 final. Haven't the Hibernate guys the same=20
> problem? Or=20
> > > are they fine with shipping a CGLIB2 beta with Hibernate=20
> 2.1 final?
> > >
> > > So I suggest to release our 1.0 RC1 shortly after Hibernate 2.1=20
> > > final, already with CGLIB2 support. As I said, we will just force=20
> > > users with full AOP proxies to upgrade to Hibernate 2.1=20
> if using the=20
> > > two in combination. We could release a 1.0 M4 shortly before that=20
> > > though, still with CGLIB1 - to ease migration paths for Hibernate=20
> > > 2.0 users.
> > >
> > > Juergen
> > >
> > >
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...]On
> > > Behalf Of Matthew E. Porter
> > > Sent: Monday, December 01, 2003 5:06 PM
> > > To: spr...@li...
> > > Subject: [Springframework-developer] Hibernate 2.1 and CGLIB
> > >
> > >
> > > I have looked through the mailing list archives but was unable to=20
> > > find
> > > the answer to my question.  Will Spring move to support=20
> Hibernate 2.1=20
> > > (as it is the new *recommended* version) and, if so, when?
> > >
> > > Also, does anyone know if I can use it now with the cglib version
> > > change?
> > >
> > >
> > >
> > > Cheers,
> > >    matthew
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SF.net Giveback Program. Does
> > > SourceForge.net help you be more productive?  Does it=20
> help you create=20
> > > better code?  SHARE THE LOVE, and help us help YOU!  Click Here:=20
> > > http://sourceforge.net/donate/=20
> > > _______________________________________________
> > > Springframework-developer mailing list=20
> > > Spr...@li...
> > >=20
> 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=20
> help you create=20
> > > better code?  SHARE THE LOVE, and help us help YOU!  Click Here:=20
> > > http://sourceforge.net/donate/=20
> > > _______________________________________________
> > > Springframework-developer mailing list=20
> > > Spr...@li...
> > >=20
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program. Does=20
> > SourceForge.net help you be more productive?  Does it help=20
> you create=20
> > better code?  SHARE THE LOVE, and help us help YOU!  Click Here:=20
> > http://sourceforge.net/donate/=20
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-developer
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program. Does=20
> > SourceForge.net help you be more productive?  Does it help=20
> you create=20
> > better code?  SHARE THE LOVE, and help us help YOU!  Click Here:=20
> > http://sourceforge.net/donate/=20
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-developer
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program. Does=20
> > SourceForge.net help you be more productive?  Does it help=20
> you create=20
> > better code?  SHARE THE LOVE, and help us help YOU!  Click Here:=20
> > http://sourceforge.net/donate/=20
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-developer
> >=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive?  Does it=20
> help you create better code?  SHARE THE LOVE, and help us=20
> help YOU!  Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

RE: [Springframework-developer] Release plan

[<tri...@tr...>]

+1 for M4 - this will get the latest StoredProcedure with Mapped ResultSet
implementation into a release quicker.  The original version using a
RowCallbackHandler was not that useful since there was nowhere to put the
results in a thread safe manner.

For the documentation, I'm approaching this the following way:

1. Create anoutline based on the central concepts and most frequently used features.
2. Fill in the outline with the JavaDoc text from the corresponding classes.
3. Enhance the text a bit.
4. Add codesamples where necessary.

At this point we should have a decent document

5. Repeat 3 and 4 until perfect :-)

Does anybody see a problem with some of the JavaDoc text beeing repeated in the
reference doc?

Thomas

Quoting "Kopylenko, Dmitry" <dko...@ac...>:

> +1 for M4. I would agree that the docs should be in "good shape" by the time
> of RC and final.
> 
> Dmitriy.
> 
> -----Original Message-----
> From: jürgen höller [werk3AT] [mailto:jue...@we...] 
> Sent: Tuesday, December 02, 2003 9:27 AM
> To: spr...@li...
> Subject: [Springframework-developer] Release plan
> 
> 
> Guys,
> 
> We need to settle on a concrete roadmap.
> 
> Despite our initial plans to go straight to RC1, I'm inclined to vote for an
> M4 in two weeks' time, with the significant reworkings that have been
> introduced in the meantime (in the bean factory and AOP area), with the
> current state of the docs, and still with CGLIB1. We can also introduce our
> JPetStore version with that release.
> 
> I suggest to target RC1 for early January then, with CGLIB2 and - most
> importantly - a proper reference manual. In the ideal case, 1.0 final could
> be ready at the end of January. M4 would correspond to a feature freeze,
> with full concentration on bugfixes and docs afterwards. RC1 should already
> be as good as it gets, a true "release candidate".
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf Of
> Matthew E. Porter
> Sent: Monday, December 01, 2003 6:37 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Hibernate 2.1 and CGLIB
> 
> 
> This was a good answer since it provides a roadmap.  Can someone post 
> this on the wiki or the website for others who may have the same 
> question?
> 
> 
> Cheers,
>    matthew
> 
> On Dec 1, 2003, at 11:04 AM, jürgen höller [werk3AT] wrote:
> 
> > Hi Matthew,
> >
> > We've been discussing that for a while. If Hibernate 2.1 gets final
> > early enough (and it seems to, being already in RC1 stage), we will 
> > switch to it for our 1.0 RCs. If 2.1 would still be far from final, we 
> > would probably have to support both CGLIB1 and CGLIB2 somehow. 
> > Fortunately, that seems not to be necessary anymore!
> >
> > For the time being, if you don't proxy full classes (but just
> > interfaces) or don't use Spring AOP in the first place, you should be 
> > able to work with Hibernate 2.1 and its CGLIB2 without hassle. The 
> > same will apply to Hibernate 2.0 users after we've moved to CGLIB2: 
> > You don't need to worry if you don't use Spring AOP will full proxies.
> >
> > I think we can live with requiring an update to Hibernate 2.1 if a
> > user wants full AOP proxies in combination. Actually, we probably 
> > *need* to move to CGLIB2 once Hibernate 2.1 final is released: Power 
> > users will want to combine full Spring AOP proxying with the current 
> > Hibernate version, not with a previous one.
> >
> > Now it would be really great if CGLIB2 were final too until Spring 1.0
> > final! :-) It's no problem to ship a CGLIB2 beta with our upcoming 
> > Spring 1.0 RC1, but it worries me to include a CGLIB2 beta in Spring 
> > 1.0 final. Haven't the Hibernate guys the same problem? Or are they 
> > fine with shipping a CGLIB2 beta with Hibernate 2.1 final?
> >
> > So I suggest to release our 1.0 RC1 shortly after Hibernate 2.1 final,
> > already with CGLIB2 support. As I said, we will just force users with 
> > full AOP proxies to upgrade to Hibernate 2.1 if using the two in 
> > combination. We could release a 1.0 M4 shortly before that though, 
> > still with CGLIB1 - to ease migration paths for Hibernate 2.0 users.
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On 
> > Behalf Of Matthew E. Porter
> > Sent: Monday, December 01, 2003 5:06 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] Hibernate 2.1 and CGLIB
> >
> >
> > I have looked through the mailing list archives but was unable to find 
> > the answer to my question.  Will Spring move to support Hibernate 2.1 
> > (as it is the new *recommended* version) and, if so, when?
> >
> > Also, does anyone know if I can use it now with the cglib version 
> > change?
> >
> >
> >
> > Cheers,
> >    matthew
> >
> >
> >
> > -------------------------------------------------------
> > 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
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> 
> -------------------------------------------------------
> 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] Release plan

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

Juergen,

Clearly telepathy...I'd also come to the conclusion that we need an M4. I
still remember how irritated I was when JBoss 3 jumped from the last beta to
the first RC and there were major changes. I didn't expect that, and I think
users may be bothered if RC1 is significantly different from the last
milestone release.

I think we could offer a patch for backward compatibility with CGLIB. Just
drop in an alaternative CglibAopProxy and CglibMethodInvocation. They share
the same public APIs. Maybe I should rename the present Cglib1AopProxy to
get rid of the 1, if we're going to take that approach.

I agree regarding a feature freeze for M4.

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>


Guys,

We need to settle on a concrete roadmap.

Despite our initial plans to go straight to RC1, I'm inclined to vote for an
M4 in two weeks' time, with the significant reworkings that have been
introduced in the meantime (in the bean factory and AOP area), with the
current state of the docs, and still with CGLIB1. We can also introduce our
JPetStore version with that release.

I suggest to target RC1 for early January then, with CGLIB2 and - most
importantly - a proper reference manual. In the ideal case, 1.0 final could
be ready at the end of January. M4 would correspond to a feature freeze,
with full concentration on bugfixes and docs afterwards. RC1 should already
be as good as it gets, a true "release candidate".

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Matthew E. Porter
Sent: Monday, December 01, 2003 6:37 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Hibernate 2.1 and CGLIB


This was a good answer since it provides a roadmap.  Can someone post
this on the wiki or the website for others who may have the same
question?


Cheers,
   matthew

On Dec 1, 2003, at 11:04 AM, jürgen höller [werk3AT] wrote:

> Hi Matthew,
>
> We've been discussing that for a while. If Hibernate 2.1 gets final
> early enough (and it seems to, being already in RC1 stage), we will
> switch to it for our 1.0 RCs. If 2.1 would still be far from final, we
> would probably have to support both CGLIB1 and CGLIB2 somehow.
> Fortunately, that seems not to be necessary anymore!
>
> For the time being, if you don't proxy full classes (but just
> interfaces) or don't use Spring AOP in the first place, you should be
> able to work with Hibernate 2.1 and its CGLIB2 without hassle. The
> same will apply to Hibernate 2.0 users after we've moved to CGLIB2:
> You don't need to worry if you don't use Spring AOP will full proxies.
>
> I think we can live with requiring an update to Hibernate 2.1 if a
> user wants full AOP proxies in combination. Actually, we probably
> *need* to move to CGLIB2 once Hibernate 2.1 final is released: Power
> users will want to combine full Spring AOP proxying with the current
> Hibernate version, not with a previous one.
>
> Now it would be really great if CGLIB2 were final too until Spring 1.0
> final! :-) It's no problem to ship a CGLIB2 beta with our upcoming
> Spring 1.0 RC1, but it worries me to include a CGLIB2 beta in Spring
> 1.0 final. Haven't the Hibernate guys the same problem? Or are they
> fine with shipping a CGLIB2 beta with Hibernate 2.1 final?
>
> So I suggest to release our 1.0 RC1 shortly after Hibernate 2.1 final,
> already with CGLIB2 support. As I said, we will just force users with
> full AOP proxies to upgrade to Hibernate 2.1 if using the two in
> combination. We could release a 1.0 M4 shortly before that though,
> still with CGLIB1 - to ease migration paths for Hibernate 2.0 users.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Matthew E. Porter
> Sent: Monday, December 01, 2003 5:06 PM
> To: spr...@li...
> Subject: [Springframework-developer] Hibernate 2.1 and CGLIB
>
>
> I have looked through the mailing list archives but was unable to find
> the answer to my question.  Will Spring move to support Hibernate 2.1
> (as it is the new *recommended* version) and, if so, when?
>
> Also, does anyone know if I can use it now with the cglib version
> change?
>
>
>
> Cheers,
>    matthew
>
>
>
> -------------------------------------------------------
> 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



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