springframework-developer — Spring Framework developers list

RE: [Springframework-developer] JIRA

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

Hmmm, hibernate is running their JIRA instance at Atlassian itself, they
probably wouldn't mind running a Spring one as well, would they? We
might as well just conatct them... 

Any volunteers?

Alef

P.s. that doesn't mean I don't wanna give up the bandwidth, it's just
that it's probably no worry for htem :)

> -----Oorspronkelijk bericht-----
> Van: spr...@li... 
> [mailto:spr...@li...]
>  Namens Kopylenko, Dmitry
> Verzonden: Wednesday, October 29, 2003 7:30 PM
> Aan: 'spr...@li...'
> Onderwerp: RE: [Springframework-developer] JIRA
> 
> 
> Sounds good.
> 
> -----Original Message-----
> From: Alef Arendsen (JTeam) [mailto:al...@jt...] 
> Sent: Wednesday, October 29, 2003 12:37 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] JIRA
> 
> 
> Codehaus sounds good, however, if it isn't possible (they're 
> hosting picocontainer, maybe they don't like us there :), I 
> don't care about running it here... There a 512kb uplink (and 
> way too much down) so that should suffice... As long as it 
> fits in our current live environment
> (JBoss/MySQL) and it does not require huge memory footprints...
> 
> Alef
> 
> > -----Oorspronkelijk bericht-----
> > Van: spr...@li...
> > [mailto:spr...@li...]
> >  Namens Colin Sampaleanu
> > Verzonden: Wednesday, October 29, 2003 6:04 PM
> > Aan: spr...@li...
> > Onderwerp: Re: [Springframework-developer] JIRA
> > 
> > 
> > +1 on the idea.   There is a question as to where it would 
> be hosted 
> > though. Maybe we could convince the CodeHaus guys to use theirs:
> >   http://jira.codehaus.org/secure/Dashboard.jspa
> > 
> > 
> > Kopylenko, Dmitry wrote:
> > 
> > > Hello everyone,
> > >
> > > Would it be a good idea to use JIRA for Spring project tracking? I
> > > just saw on their site that they have a free license for
> > open source
> > > projects.
> > >
> > > What do you think?
> > >
> > > Regards,
> > > Dmitriy.
> > >
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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
> 
> 
> -------------------------------------------------------
> 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] JIRA

[Kopylenko, D. <dko...@ac...>]

Sounds good.

-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...] 
Sent: Wednesday, October 29, 2003 12:37 PM
To: spr...@li...
Subject: RE: [Springframework-developer] JIRA


Codehaus sounds good, however, if it isn't possible (they're hosting
picocontainer, maybe they don't like us there :), I don't care about running
it here... There a 512kb uplink (and way too much down) so that should
suffice... As long as it fits in our current live environment
(JBoss/MySQL) and it does not require huge memory footprints...

Alef

> -----Oorspronkelijk bericht-----
> Van: spr...@li...
> [mailto:spr...@li...]
>  Namens Colin Sampaleanu
> Verzonden: Wednesday, October 29, 2003 6:04 PM
> Aan: spr...@li...
> Onderwerp: Re: [Springframework-developer] JIRA
> 
> 
> +1 on the idea.   There is a question as to where it would be hosted 
> though. Maybe we could convince the CodeHaus guys to use theirs:
>   http://jira.codehaus.org/secure/Dashboard.jspa
> 
> 
> Kopylenko, Dmitry wrote:
> 
> > Hello everyone,
> >
> > Would it be a good idea to use JIRA for Spring project tracking? I 
> > just saw on their site that they have a free license for
> open source
> > projects.
> >
> > What do you think?
> >
> > Regards,
> > Dmitriy.
> >
> 
> 
> 
> 
> -------------------------------------------------------
> 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] JIRA

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

Codehaus sounds good, however, if it isn't possible (they're hosting
picocontainer, maybe they don't like us there :), I don't care about
running it here... There a 512kb uplink (and way too much down) so that
should suffice... As long as it fits in our current live environment
(JBoss/MySQL) and it does not require huge memory footprints...

Alef

> -----Oorspronkelijk bericht-----
> Van: spr...@li... 
> [mailto:spr...@li...]
>  Namens Colin Sampaleanu
> Verzonden: Wednesday, October 29, 2003 6:04 PM
> Aan: spr...@li...
> Onderwerp: Re: [Springframework-developer] JIRA
> 
> 
> +1 on the idea.   There is a question as to where it would be hosted 
> though. Maybe we could convince the CodeHaus guys to use theirs:
>   http://jira.codehaus.org/secure/Dashboard.jspa
> 
> 
> Kopylenko, Dmitry wrote:
> 
> > Hello everyone,
> >
> > Would it be a good idea to use JIRA for Spring project tracking? I
> > just saw on their site that they have a free license for 
> open source 
> > projects.
> >
> > What do you think?
> >
> > Regards,
> > Dmitriy.
> >
> 
> 
> 
> 
> -------------------------------------------------------
> 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] JIRA

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

+1 on the idea.   There is a question as to where it would be hosted 
though. Maybe we could convince the CodeHaus guys to use theirs:
  http://jira.codehaus.org/secure/Dashboard.jspa


Kopylenko, Dmitry wrote:

> Hello everyone,
>
> Would it be a good idea to use JIRA for Spring project tracking? I 
> just saw on their site that they have a free license for open source 
> projects.
>
> What do you think?
>
> Regards,
> Dmitriy.
>

Re: [Springframework-developer] JIRA

[William G. T. Jr. <wg...@ru...>]

+1 for JIRA!

Cameron Braid wrote:

> I think it is a great idea.
> 
> WebWork and Hibernate use JIRA, and we use it internally.
> 
> It is a great product.
> 
> Cameron
> 
> Kopylenko, Dmitry wrote:
> 
>> Hello everyone,
>>
>> Would it be a good idea to use JIRA for Spring project tracking? I 
>> just saw on their site that they have a free license for open source 
>> projects.
>>
>> What do you think?
>>
>> Regards,
>> Dmitriy.
>>
> 

RE: [Springframework-developer] JIRA

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

+1

> -----Oorspronkelijk bericht-----
> Van: spr...@li... 
> [mailto:spr...@li...]
>  Namens Cameron Braid
> Verzonden: Wednesday, October 29, 2003 2:16 PM
> Aan: spr...@li...
> Onderwerp: Re: [Springframework-developer] JIRA
> 
> 
> I think it is a great idea.
> 
> WebWork and Hibernate use JIRA, and we use it internally.
> 
> It is a great product.
> 
> Cameron
> 
> Kopylenko, Dmitry wrote:
> 
> > Hello everyone,
> >
> > Would it be a good idea to use JIRA for Spring project tracking? I
> > just saw on their site that they have a free license for 
> open source 
> > projects.
> >
> > What do you think?
> >
> > Regards,
> > Dmitriy.
> >
> 
> 
> -- 
> Any damn fool can write code that a computer can 
> understand... The trick is to write code that humans can 
> understand. [Martin Fowler 
> http://www.martinfowler.com/distributedComputi> ng/refactoring.pdf]
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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] JIRA

[Cameron B. <ca...@da...>]

I think it is a great idea.

WebWork and Hibernate use JIRA, and we use it internally.

It is a great product.

Cameron

Kopylenko, Dmitry wrote:

> Hello everyone,
>
> Would it be a good idea to use JIRA for Spring project tracking? I 
> just saw on their site that they have a free license for open source 
> projects.
>
> What do you think?
>
> Regards,
> Dmitriy.
>


-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]

[Springframework-developer] JIRA

[Kopylenko, D. <dko...@ac...>]

Hello everyone,

Would it be a good idea to use JIRA for Spring project tracking? I just saw
on their site that they have a free license for open source projects.

What do you think?

Regards,
Dmitriy.

[Springframework-developer] Easymock upgraded to 1.0.1

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

I've updated easymock.jar in Spring from 1.0 to 1.0.1. It adds some 
minor enhancements.

This upgrade does not appear to have affected broken any tests. Test 
previously and still broken (on my system) are:
  AttributeWriterTests
  CompilerTests
  FormatHelperTests

Regards,
Colin


Colin Sampaleanu wrote:

>
> -------- Original Message --------
> Subject:     [easymock] EasyMock 1.0.1 available
> Date:     Tue, 21 Oct 2003 01:45:01 +0200
> From:     Tammo Freese <fr...@ac...>
> Reply-To:     eas...@ya...
> To:     eas...@ya...
>
>
>
> Hello all,
>
> I have uploaded EasyMock 1.0.1. Changes:
>
> - convenience methods expectAndReturn() and expectAndThrow()
>   (no JavaDoc yet, but tests and documentation)
>
> - numerous refactorings to open up EasyMock for extensions
>   (beware, all the internal stuff may change without notice)
>
> Please let me know whether you like the new convenience methods or not.
>
> -
> Tammo
>
> PS I have done a short exploration to port the EasyMock class extension
> (which Joel Shellman provided on the file section) to EasyMock 1.0.1.
> If anyone is interested, please let me know.

Re: [Springframework-developer] Question about need for DAo's or Business Objects to keep a session factory refrence

[Cameron B. <ca...@da...>]

Yeah, the autowire looks handy for those sort of cases.. I was just 
reading up on it today.. since I want to use it to autowire xwork 
actions... see my other post about this one.

Cheers,

Cameron

Colin Sampaleanu wrote:

> Not quite, but you can use Spring's autowire support. That is, your 
> mapper/dao beans in the app context would be set to autowire, and 
> could be fed the Session Factory instance without you actually having 
> to specify it. I generally don't use autowire, preferring to specify 
> dependencies directly, but in this case, when you might have 10-30 
> mappers taking the same parameter, it should work nicely. Here's an 
> excerpt from the Spring app context dtd describing the autowire stuff:
>
> <!ATTLIST bean dependency-check (none|objects|simple|all) "none">
>
> <!--
>    Optional attribute controlling whether to "autowire"
>    bean properties. This is an automagical process in which bean 
> references
>    don't need to be coded explicitly in the XML bean definition file,
>    but Spring works out dependencies.
>      There are three modes:
>      1. no
>    The traditional Spring default. No automagical wiring. Bean references
>    must be defined in the XML file via the <ref> element. We recommend 
> this
>    in most cases as it makes documentation more explicit.
>      2. byName
>    Autowiring by property name. If a bean of class Cat exposes a dog 
> property,
>    Spring will try to set this to the value of the bean "dog" in the 
> current
>    factory.
>      3. byType
>    This is like the PicoContainer default, in which there must be exactly
>    one bean of the property type in the bean factory. If there are 0 or
>    more than one, a fatal error is raised, and you can't use byType 
> autowiring for
>    that bean.
>    This makes bean factories simple to configure for small namespaces,
>    but doesn't work as well as standard Spring behaviour for
>    bigger applications.
>      Autowire behaviour can be combined with dependency checking, 
> which will
>    be performed after all auto wiring has been completed.
> -->
> <!ATTLIST bean autowire (no|byName|byType) "no">
>
>
> So in the case of using HibernateDaoSupport as a base for your 
> mappers, you would autowire (by explicit name or by type) the property 
> called 'sessionFactory' for those mappers (which they just inherit 
> from HibernateDaoSupport).
>
> Regards,
> Colin
>
>
>
> Cameron Braid wrote:
>
>> Thanks for y our prompt reply.
>>
>> Yeah, that all makes sense.
>>
>> In regards to mapping for an abstract class - is it possible to 
>> specify a mapping that gets inherited automatically, based on the 
>> class hierarchy
>>
>> i.e. Map the HibernateDaoSupport.sessionFactory property to name 
>> "mySessionFactory", and then any class that extends 
>> HibernateDaoSupport inherit that mapping ?
>>
>> Thanks again.
>>
>> Cameron.
>>
>> Colin Sampaleanu wrote:
>>
>>> Cameron Braid wrote:
>>>
>>>> I am just beginning to use the Spring framework, and so far I am 
>>>> very impressed.
>>>>
>>>> One thing that I don't quite understand is the mandatory 
>>>> requirement for each DAO and BO (Business Object) to support the 
>>>> set/getSessionFactory method.
>>>>
>>>> The reason that I say it is mandatory is because the only way to 
>>>> obtain the current session (as far as I know) is to use 
>>>> SessionFactoryUtils.getSession(SessionFactory...).  This means that 
>>>> each DAO/BO requires a setSessionFactory property to be able to be 
>>>> passed it from the spring container.  This also requires that each 
>>>> DAO/BO to be configured to bind the SessionFactory instance within 
>>>> the applicationContext.xml
>>>>
>>>> What I would think would be a simple and quite common use case 
>>>> would be for an app to require only one session factory. Therefore 
>>>> I think that the SessionFactoryUtils, and related classes , could 
>>>> use a static field to store the 'default' session factory.
>>>>
>>>> Has something like this been considered ?
>>>> Do you think that this is a good or a bad idea ?
>>>>
>>> Cameron,
>>>
>>> To clarify, your business objects would generally do not need to 
>>> have a setSessionFactory method. They would need setters for one or 
>>> more Mapper/DAO objects, and those Mapper/DAO objects would need the 
>>> setSessionFactory method.
>>>
>>> As for the idea of having the Mapper/DAO objects not need the 
>>> session factory parameter, and getting it from a singleton of some 
>>> sort, that approach would work for some use cases, but using a 
>>> singleton like this is just not very clean. It becomes harder to 
>>> test code in isolation, and usually locks you into the singleton 
>>> approach.
>>>
>>> You are at most going to declare each mapper/dao once in the 
>>> application context. Giving it the session factory paramter is not a 
>>> big deal. In terms of the actual code in the mapper/dao to support 
>>> this, this can be provided by an abstract base class, and in fact 
>>> Spring has such a class (for Hibernate) called HibernateDaoSupport.
>>>
>>> Regards,
>>> Colin
>>
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Question about need for DAo's or Business Objects to keep a session factory refrence

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

Not quite, but you can use Spring's autowire support. That is, your 
mapper/dao beans in the app context would be set to autowire, and could 
be fed the Session Factory instance without you actually having to 
specify it. I generally don't use autowire, preferring to specify 
dependencies directly, but in this case, when you might have 10-30 
mappers taking the same parameter, it should work nicely. Here's an 
excerpt from the Spring app context dtd describing the autowire stuff:

<!ATTLIST bean dependency-check (none|objects|simple|all) "none">

<!--
    Optional attribute controlling whether to "autowire"
    bean properties. This is an automagical process in which bean references
    don't need to be coded explicitly in the XML bean definition file,
    but Spring works out dependencies.
   
    There are three modes:
   
    1. no
    The traditional Spring default. No automagical wiring. Bean references
    must be defined in the XML file via the <ref> element. We recommend this
    in most cases as it makes documentation more explicit.
   
    2. byName
    Autowiring by property name. If a bean of class Cat exposes a dog 
property,
    Spring will try to set this to the value of the bean "dog" in the 
current
    factory.
   
    3. byType
    This is like the PicoContainer default, in which there must be exactly
    one bean of the property type in the bean factory. If there are 0 or
    more than one, a fatal error is raised, and you can't use byType 
autowiring for
    that bean.
    This makes bean factories simple to configure for small namespaces,
    but doesn't work as well as standard Spring behaviour for
    bigger applications.
   
    Autowire behaviour can be combined with dependency checking, which will
    be performed after all auto wiring has been completed.
-->
<!ATTLIST bean autowire (no|byName|byType) "no">


So in the case of using HibernateDaoSupport as a base for your mappers, 
you would autowire (by explicit name or by type) the property called 
'sessionFactory' for those mappers (which they just inherit from 
HibernateDaoSupport).

Regards,
Colin



Cameron Braid wrote:

> Thanks for y our prompt reply.
>
> Yeah, that all makes sense.
>
> In regards to mapping for an abstract class - is it possible to 
> specify a mapping that gets inherited automatically, based on the 
> class hierarchy
>
> i.e. Map the HibernateDaoSupport.sessionFactory property to name 
> "mySessionFactory", and then any class that extends 
> HibernateDaoSupport inherit that mapping ?
>
> Thanks again.
>
> Cameron.
>
> Colin Sampaleanu wrote:
>
>> Cameron Braid wrote:
>>
>>> I am just beginning to use the Spring framework, and so far I am 
>>> very impressed.
>>>
>>> One thing that I don't quite understand is the mandatory requirement 
>>> for each DAO and BO (Business Object) to support the 
>>> set/getSessionFactory method.
>>>
>>> The reason that I say it is mandatory is because the only way to 
>>> obtain the current session (as far as I know) is to use 
>>> SessionFactoryUtils.getSession(SessionFactory...).  This means that 
>>> each DAO/BO requires a setSessionFactory property to be able to be 
>>> passed it from the spring container.  This also requires that each 
>>> DAO/BO to be configured to bind the SessionFactory instance within 
>>> the applicationContext.xml
>>>
>>> What I would think would be a simple and quite common use case would 
>>> be for an app to require only one session factory. Therefore I think 
>>> that the SessionFactoryUtils, and related classes , could use a 
>>> static field to store the 'default' session factory.
>>>
>>> Has something like this been considered ?
>>> Do you think that this is a good or a bad idea ?
>>>
>> Cameron,
>>
>> To clarify, your business objects would generally do not need to have 
>> a setSessionFactory method. They would need setters for one or more 
>> Mapper/DAO objects, and those Mapper/DAO objects would need the 
>> setSessionFactory method.
>>
>> As for the idea of having the Mapper/DAO objects not need the session 
>> factory parameter, and getting it from a singleton of some sort, that 
>> approach would work for some use cases, but using a singleton like 
>> this is just not very clean. It becomes harder to test code in 
>> isolation, and usually locks you into the singleton approach.
>>
>> You are at most going to declare each mapper/dao once in the 
>> application context. Giving it the session factory paramter is not a 
>> big deal. In terms of the actual code in the mapper/dao to support 
>> this, this can be provided by an abstract base class, and in fact 
>> Spring has such a class (for Hibernate) called HibernateDaoSupport.
>>
>> Regards,
>> Colin
>

Re: [Springframework-developer] Question about need for DAo's or Business Objects to keep a session factory refrence

[Cameron B. <ca...@da...>]

Thanks for y our prompt reply.

Yeah, that all makes sense.

In regards to mapping for an abstract class - is it possible to specify 
a mapping that gets inherited automatically, based on the class hierarchy

i.e. Map the HibernateDaoSupport.sessionFactory property to name 
"mySessionFactory", and then any class that extends HibernateDaoSupport 
inherit that mapping ?

Thanks again.

Cameron.

Colin Sampaleanu wrote:

> Cameron Braid wrote:
>
>> I am just beginning to use the Spring framework, and so far I am very 
>> impressed.
>>
>> One thing that I don't quite understand is the mandatory requirement 
>> for each DAO and BO (Business Object) to support the 
>> set/getSessionFactory method.
>>
>> The reason that I say it is mandatory is because the only way to 
>> obtain the current session (as far as I know) is to use 
>> SessionFactoryUtils.getSession(SessionFactory...).  This means that 
>> each DAO/BO requires a setSessionFactory property to be able to be 
>> passed it from the spring container.  This also requires that each 
>> DAO/BO to be configured to bind the SessionFactory instance within 
>> the applicationContext.xml
>>
>> What I would think would be a simple and quite common use case would 
>> be for an app to require only one session factory. Therefore I think 
>> that the SessionFactoryUtils, and related classes , could use a 
>> static field to store the 'default' session factory.
>>
>> Has something like this been considered ?
>> Do you think that this is a good or a bad idea ?
>>
> Cameron,
>
> To clarify, your business objects would generally do not need to have 
> a setSessionFactory method. They would need setters for one or more 
> Mapper/DAO objects, and those Mapper/DAO objects would need the 
> setSessionFactory method.
>
> As for the idea of having the Mapper/DAO objects not need the session 
> factory parameter, and getting it from a singleton of some sort, that 
> approach would work for some use cases, but using a singleton like 
> this is just not very clean. It becomes harder to test code in 
> isolation, and usually locks you into the singleton approach.
>
> You are at most going to declare each mapper/dao once in the 
> application context. Giving it the session factory paramter is not a 
> big deal. In terms of the actual code in the mapper/dao to support 
> this, this can be provided by an abstract base class, and in fact 
> Spring has such a class (for Hibernate) called HibernateDaoSupport.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Question about need for DAo's or Business Objects to keep a session factory refrence

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

Cameron Braid wrote:

> I am just beginning to use the Spring framework, and so far I am very 
> impressed.
>
> One thing that I don't quite understand is the mandatory requirement 
> for each DAO and BO (Business Object) to support the 
> set/getSessionFactory method.
>
> The reason that I say it is mandatory is because the only way to 
> obtain the current session (as far as I know) is to use 
> SessionFactoryUtils.getSession(SessionFactory...).  This means that 
> each DAO/BO requires a setSessionFactory property to be able to be 
> passed it from the spring container.  This also requires that each 
> DAO/BO to be configured to bind the SessionFactory instance within the 
> applicationContext.xml
>
> What I would think would be a simple and quite common use case would 
> be for an app to require only one session factory. Therefore I think 
> that the SessionFactoryUtils, and related classes , could use a static 
> field to store the 'default' session factory.
>
> Has something like this been considered ?
> Do you think that this is a good or a bad idea ?
>
Cameron,

To clarify, your business objects would generally do not need to have a 
setSessionFactory method. They would need setters for one or more 
Mapper/DAO objects, and those Mapper/DAO objects would need the 
setSessionFactory method.

As for the idea of having the Mapper/DAO objects not need the session 
factory parameter, and getting it from a singleton of some sort, that 
approach would work for some use cases, but using a singleton like this 
is just not very clean. It becomes harder to test code in isolation, and 
usually locks you into the singleton approach.

You are at most going to declare each mapper/dao once in the application 
context. Giving it the session factory paramter is not a big deal. In 
terms of the actual code in the mapper/dao to support this, this can be 
provided by an abstract base class, and in fact Spring has such a class 
(for Hibernate) called HibernateDaoSupport.

Regards,
Colin

[Springframework-developer] Question about need for DAo's or Business Objects to keep a session factory refrence

[Cameron B. <ca...@da...>]

I am just beginning to use the Spring framework, and so far I am very 
impressed.

One thing that I don't quite understand is the mandatory requirement for 
each DAO and BO (Business Object) to support the set/getSessionFactory 
method.

The reason that I say it is mandatory is because the only way to obtain 
the current session (as far as I know) is to use 
SessionFactoryUtils.getSession(SessionFactory...).  This means that each 
DAO/BO requires a setSessionFactory property to be able to be passed it 
from the spring container.  This also requires that each DAO/BO to be 
configured to bind the SessionFactory instance within the 
applicationContext.xml

What I would think would be a simple and quite common use case would be 
for an app to require only one session factory. Therefore I think that 
the SessionFactoryUtils, and related classes , could use a static field 
to store the 'default' session factory.

Has something like this been considered ?
Do you think that this is a good or a bad idea ?

Cheers,

Cameron.

[Springframework-developer] autoWire support

[Cameron B. <ca...@da...>]

Is there any way that the auto wire support could be exposed through a 
public API to allow it to be used outside of the RootBeanDefinition class.

I am trying to implement a Xwork Interceptor that auto wires an action's 
properties that are components.

Currently I am able to manually wire them by specifying an "action 
property name" to "spring component name" mapping in the xwork interceptor,
now I wish to be able to auto wire them by calling something like 
appContext.autoWireByName(action)

Cheers,

Cameron.

RE: [Springframework-developer] LocalSessionFactory afterPropertiesSet() = final

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

I talked it over and the callback seems like a good idea, it removes the
need for doing the super.newSessionFactory call in the first solution.
=20
I'll add it...
=20
alef
=20

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
j=FCrgen h=F6ller [werk3AT]
Verzonden: Friday, October 24, 2003 1:08 PM
Aan: spr...@li...
Onderwerp: RE: [Springframework-developer] LocalSessionFactory
afterPropertiesSet() =3D final


Alef,
=20
I'd like to keep the final afterPropertiesSet -- it's too easy to break
superclass functionality if overriding that and not properly doing super
calls. Currently, you could override newSessionFactory a la:
=20
protected SessionFactory newSessionFactory(Configuration config) {
  // add the mapping resources programmatically
  config.addResource("myMappingResource",
Thread.currentThread().getContextClassLoader());
  return super.newSessionFactory(config);
}
=20
Of course, it might make sense to introduce a separate post-processing
callback, to be invoked by the standard afterPropertiesSet method right
before the newSessionFactory call:
=20

protected void postProcessConfiguration(Configuration config) {
  // add the mapping resources programmatically
  config.addResource("myMappingResource",
Thread.currentThread().getContextClassLoader());
}
=20
What do you think? I guess such a call back wouldn't hurt anyone, and it
is easier to override for post-processing purposes.
=20
Juergen
=20
=20

-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...]
Sent: Thursday, October 23, 2003 2:50 PM
To: 'Spring Developers'
Subject: [Springframework-developer] LocalSessionFactory
afterPropertiesSet() =3D final



Juergen,=20

Right now the LocalSessionFactory in the Hibernate package has a final
afterPropertiesSet()-method. We'd like to extend the factory in order to
collect mapping files from different sources instead of the fixed
property 'mappingResources'. Then of course we need to override
afterPropertiesSet() to set the mappingResources on the superclass and
then call super.afterPropertiesSet(). However, like I said, the
afterPropertiesSet() method from LocalSessionFactory is final.

Any objections to 'de-finalizing' this method?=20

Thanx,=20

Alef=20

P.s. getting into the hibernate stuff here, looks good :)=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

Re: [Springframework-developer] StaticMethodPointcut

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

It's changed.

R
----- Original Message ----- 
From: "Trevor Cook" <pr...@se...>
To: <spr...@li...>
Sent: Monday, October 27, 2003 1:45 AM
Subject: RE: [Springframework-developer] StaticMethodPointcut


> +1
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Rod Johnson
> Sent: October 24, 2003 8:44 AM
> To: spr...@li...
> Subject: [Springframework-developer] StaticMethodPointcut
>
>
> Guys,
>
> I think we should change the signature on the StaticMethodPointcut
applies()
> method to introduce a new argument, targetClass, as below:
>
> boolean applies(Method method, Class targetClass, AttributeRegistry
> attributeRegistry);
>
> The reason is that sometimes we need to know not just the method, but the
> target class we're invoking.
>
> Consider the getAge() method on class TestBean. A subclass,
SpecialTestBean
> adds a class-level metadata attribute that should cause auto-proxying.
With
> the old signature, the method argument would be TestBean.getAge() and
> without knowledge of the target class we would miss this important
> attribute.
>
> Does everyone agree this makes sense? Is there a better solution?
>
> This will break existing static pointcuts, although it's trivial to fix.
> I've already revised the source and test tree (although not committed
yet).
> Hence I didn't commit it before M2.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.530 / Virus Database: 325 - Release Date: 22/10/2003
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] StaticMethodPointcut

[Trevor C. <pr...@se...>]

+1

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: October 24, 2003 8:44 AM
To: spr...@li...
Subject: [Springframework-developer] StaticMethodPointcut


Guys,

I think we should change the signature on the StaticMethodPointcut applies()
method to introduce a new argument, targetClass, as below:

boolean applies(Method method, Class targetClass, AttributeRegistry
attributeRegistry);

The reason is that sometimes we need to know not just the method, but the
target class we're invoking.

Consider the getAge() method on class TestBean. A subclass, SpecialTestBean
adds a class-level metadata attribute that should cause auto-proxying. With
the old signature, the method argument would be TestBean.getAge() and
without knowledge of the target class we would miss this important
attribute.

Does everyone agree this makes sense? Is there a better solution?

This will break existing static pointcuts, although it's trivial to fix.
I've already revised the source and test tree (although not committed yet).
Hence I didn't commit it before M2.

Regards,
Rod




-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 22/10/2003

Re: [Springframework-developer] Re: XWork/Spring integration

[Cameron B. <ca...@da...>]

I am cross posting this message because it is a response to one on the
Spring Framework list, and it is more WebWork/Xwork related.

I was thinking of doing a similiar thing as outlined below, but instead
of introducing a new <external-ref> tag into the xwork.xml config files,
I was going to do it with an interceptor.

Therefore I would configure the interceptor using <params to tell it
which component names map to which action properties.


<action name="Bar" class="mypackage.MyAction"> 

     <param name="foo">17</param> 
     <interceptor-ref name="springContainer">
        <param name="dataSource">myDataSource</param>
     </interceptor-ref>
</action> 

I do like the idea of supporting an external-ref type syntax, if other
people think it is a better idea.

Cheers,

Cameron


On Sun, 2003-10-26 at 04:09, jürgen höller [werk3AT] wrote:

> Hi Matthew, 
> 
> I suggest to add the "external-ref" tag to the XWork XML file itself, just like the existing "param" tag. This is basically an inversion of the current XWork component approach -- "pulling" in named component instances instead of "pushing" them to the actions.
> 
>   <action name="Bar" class="mypackage.MyAction"> 
>      <param name="foo">17</param> 
>      <external-ref name="bar">myDataSource</external-ref> 
>   </action> 
> 
> The MyAction class could look as follows. Note that there's no enabler interface involved; the bean property and thus the setter is determined via external-ref´s "name" attribute, just like with the param tag.
> 
>   public class MyAction implements Action { 
>     private DataSource dataSource; 
>     public void setDataSource(DataSource dataSource) { 
>       this.dataSource = dataSource; 
>     } 
>     ... 
>   } 
> 
> As this involves support in the XWork XML file, the XWork action processor will need to implement the external-ref resolution itself instead of an interceptor like ComponentInterceptor. It could delegate the actual resolution to an ExternalReferenceResolver strategy:
> 
>   public interface ExternalReferenceResolver { 
>     Object resolveReference(String name); 
>   } 
> 
> In case of WebWork2 being the XWork environment, ServletDispatcher could determine the ExternalReferenceResolver implementation class name from a servlet init-param. The Spring implementation for a web environment would simply retrieve the root web application context via the ServletContext then, possibly receiving the latter via a ServletContextAware interface.
> 
>   public class SpringServletContextReferenceResolver implements ExternalReferenceResolver, ServletContextAware { 
>     private void ApplicationContext applicationContext; 
>     public void setServletContext(ServletContext servletContext) { 
>       this.applicationContext = WebApplicationContextUtils.getWebApplicationContext(servletContext); 
>     } 
>     public Object resolveReference(String name) { 
>       return this.applicationContext.getBean(name); 
>     } 
>   } 
> 
> The Spring root web application context would be loaded on startup via Spring's ContextLoaderListener, as usual. Spring/WebWork2 web apps would thus just use Spring's typical "WEB-INF/applicationContext.xml" for defining middle tier resources and business objects plus XWork's "xwork.xml" for defining use-case-driven actions. There´s no "components.xml" involved, except if the web app uses XWork's scoped components mechanism too. That would keep configuration simple and concise enough for typical needs.
> 
> The Spring application context will always be an application-level singleton. In a WebWork2 combo, there are no nested application contexts from a Spring web MVC DispatcherServlet involved -- WebWork2 serves as web MVC framework then. Note that an application context can create either singleton beans or new instances from a prototype, configurable via the bean definition. The external reference mechanism above would not need to be concerned with that distinction, it could transparently work with both kinds; but typical middle tier objects are almost always singletons anyway.
> 
> A non-web XWork dispatcher could be configured with a different Spring resolver implementation, using a ClassPathXmlApplicationContext instead of a preloaded XmlWebApplicationContext. It would look for an "applicationContext.xml" resource in the root of the class path.
> 
>   public class SpringClassPathReferenceResolver implements ExternalReferenceResolver { 
>     private void ApplicationContext applicationContext; 
>     public SpringClassPathReferenceResolver() { 
>       this.applicationContext = new ClassPathXmlApplicationContext("/applicationContext.xml"); 
>     } 
>     public Object resolveReference(String name) { 
>       return this.applicationContext.getBean(name); 
>     } 
>   } 
> 
> The whole concept is pretty orthogonal to XWork's existing scoped component approach. For example, a webshop could leverage an XWork component for a session-scoped shopping cart *and* Spring-managed business objects for loading product information and for turning that shopping cart into a persistent order.
> 
> BTW, an ad-hoc solution for accessing a Spring root web application context from a WebWork action could be to make the action HttpServletRequestAware and do the application context lookup manually. That would work without special support, even on WebWork1.
> 
>   ... 
>   ServletContext servletContext = request.getSession().getServletContext(); 
>   ApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(servletContext); 
>   MyBusinessObject businessObject = (MyBusinessObject) applicationContext.getBean("myBusinessObject"); 
>   ... 
> 
> Of course, an external reference resolver solution would be way preferable because it allows the actions to receive references to business objects via simple bean property setters of the business object type; no custom lookup code and especially no web dependencies in the actions necessary.
> 
> What do you think? Do you see a different option for integration? I'm not keen on letting Spring touch the XWork action instances directly; that would involve double definitions in both xwork.xml and applicationContext.xml. components.xml isn't a good integration point either, as it would involve double definitions too. I believe that my proposal is straightforward and intuitive, as it applies a similar notation for both action params and external references. Of course, it introduces a new concept to xwork.xml -- but I believe a powerful and generic one.
> 
> Juergen 
> 
> 
> -----Ursprüngliche Nachricht----- 
> Von: Matthew E. Porter [mailto:ma...@me...] 
> Gesendet: Fr 24.10.2003 22:23 
> An: jürgen höller [werk3AT] 
> Cc: 
> Betreff: Re: XWork/Spring integration 
> 
> 
> Jüergen: 
>    I may start working on the spring-ww2 integration this weekend if I 
> get some time.  I have some questions about this proposal and how the 
> system will work.  Please forgive me if these questions seem 
> rudimentary, as I am still learning Spring. 
>    Are you talking about adding the "external-ref" tag to 
> components.xml?  In this case, I would assume it would replace the 3 
> scope concept in XW with Spring's application and Web-MVC scope.  Or am 
> I just wrong?  How would Actions be wired in? 
> 
> 
> Cheers, 
>    matthew 
> 
> On Thursday, October 9, 2003, at 12:16 PM, jürgen höller [werk3AT] 
> wrote: 
> 
> > Matthew, Mike, 
> > 
> > Hmmm, I'm not always too keen in terms of perception... anyway: Hi 
> > Matthew, I don't think I can to tell you anything about Conductor that 
> > you wouldn't already know ;-) 
> > 
> > In terms of effort, I expect my XWork proposal to be pretty 
> > straightforward to implement: It's basically just about introducing 
> > the "external-ref" tag and an "ExternalReferenceResolver" interface 
> > that the tag delegates to. A Spring implementation of that interface 
> > should be easy to do too: Load the application context in some init 
> > method, and resolve the references as bean names in the context. 
> > 
> > The only issue is where to load the application context from: If this 
> > should be possible from the WEB-INF directory, we would need a 
> > reference to the ServletContext in the SpringReferenceResolver 
> > implementation. Else, we could use ClassPathXmlApplicationContext to 
> > load the XML file from the class path: This would not involve anything 
> > special at all. 
> > 
> > So in fact, the interface would need an init method: 
> > 
> >   public interface ExternalReferenceResolver { 
> >     void init(); 
> >     Object resolveReference(String name); 
> >   } 
> > 
> > A Spring implementation could look as follows: 
> > 
> >   public class SpringReferenceResolver implements 
> > ExternalReferenceResolver { 
> >     private ApplicationContext applicationContext; 
> >     public void init() { 
> >       applicationContext = new 
> > ClassPathXmlApplicationContext("/spring-context.xml"); 
> >     } 
> >     public Object resolveReference(String name) { 
> >       return applicationContext.getBean(name); 
> >     } 
> >   } 
> > 
> > It doesn't need to be more complicated than this. We would just need 
> > to introduce such external reference hooks in XWork. I do not consider 
> > an "external-ref" tag as much extra XML; and it's easy to specify 
> > references to specific bean instances with it. What do you think? 
> > 
> > Juergen 
> > 
> > 
> > -----Original Message----- 
> > From: jürgen höller [werk3AT] 
> > Sent: Thursday, October 09, 2003 6:33 PM 
> > To: Matthew E. Porter 
> > Cc: spr...@li...; 
> > spr...@li... 
> > Subject: [Springframework-developer] RE: [Springframework-user] 
> > Introduction and Hibernate-Spring queries 
> > 
> > 
> > Not yet. Maybe Mike can comment on a timeframe, although Jason might 
> > be the one that actually works on it. Note that this plan is not fixed 
> > at all; currently, XWork has its own enable-interface-centric simple 
> > IoC support. I'm just "consulting" on this issue; Mike, Jason, and the 
> > other XWork guys will have to decide on what to adopt in the end. 
> > 
> > Juergen 
> > 
> > 
> > -----Original Message----- 
> > From: Matthew E. Porter [mailto:ma...@me...] 
> > Sent: Thursday, October 09, 2003 6:31 PM 
> > To: jürgen höller [werk3AT] 
> > Cc: spr...@li...; 
> > spr...@li... 
> > Subject: Re: [Springframework-user] Introduction and Hibernate-Spring 
> > queries 
> > 
> > 
> > Has any work (i.e. code) been done on this? 
> > 
> > 
> > Cheers, 
> >    matthew 
> > 
> > On Thursday, October 9, 2003, at 11:15 AM, jürgen höller [werk3AT] 
> > wrote: 
> > 
> >> Matthew, everybody, 
> >> 
> >> My XWork/Spring integration proposal is no secret -- here it is, cut 
> >> from a recent mail to Jason and Mike. We've been discussing IoC 
> >> options for XWork/Conductor for quite a while, mainly in terms of 
> >> PicoContainer vs Spring. 
> >> 
> >> <quote> 
> >> 
> >> As far as I see, the XWork config file supports setting bean 
> >> properties as parameters on actions like this: 
> >> 
> >>   <action name="Bar" class="com.opensymphony.xwork.SimpleAction"> 
> >>     <param name="foo">17</param> 
> >>     <param name="bar">23</param> 
> >>   </action> 
> >> 
> >> This is obviously pretty similar to a Spring bean definition, just 
> >> specific for a WebWork action. A significant difference is that the 
> >> Spring property tag can tag either a value tag or a ref tag within, 
> >> i.e. either specify a parameter value or a´dependency on another bean. 
> >> 
> >> Currently, I see the easiest way of accessing a Spring context from 
> >> XWork via a tag that resolves an external component reference, a la: 
> >> 
> >>   <action name="Bar" class="com.opensymphony.xwork.SimpleAction"> 
> >>     <param name="foo">17</param> 
> >>     <external-ref name="bar">myDataSource</external-ref> 
> >>   </action> 
> >> 
> >> XWork could fetch the Spring context then, look up the bean named 
> >> "myDataSource", and set the reference into the "bar" bean property of 
> >> the "Bar" action. This would be intuitive, as it works analogously to 
> >> setting a parameter value, and flexible, as it allows to reference any 
> >> specific instance. Effectively, you would be accessing beans in a 
> >> Spring middle tier context rather than letting Spring touch your 
> >> action instances - but that's not a disadvantage, rather a clean 
> >> separation of responsibilities. 
> >> 
> >> Of course, the Spring support for such external references can be 
> >> pluggable in XWork, potentially replacing the current ComponentManager 
> >> mechanism with its enabler interfaces. Any such resolver for external 
> >> references would simply need to return an object for the given 
> >> symbolic name. The interface could look like this: 
> >> 
> >>   public interface ExternalReferenceResolver { 
> >>     Object resolveReference(String name); 
> >>   } 
> >> 
> >> A Spring implementation would grab a reference to the Spring 
> >> application context and call getBean with the given name. The 
> >> application context itself could get initialized on XWork startup, 
> >> initializing its singletons upfront. I consider such an XWork/Spring 
> >> integration as pretty simple but very powerful: no enabler interfaces, 
> >> just bean properties with component types, and an external-ref tag in 
> >> addition to the param tag. 
> >> 
> >> </quote> 
> >> 
> >> Juergen 
> >> 
> >> 
> >> -----Original Message----- 
> >> From: Matthew E. Porter [mailto:ma...@me...] 
> >> Sent: Thursday, October 09, 2003 4:16 PM 
> >> To: jürgen höller [werk3AT] 
> >> Subject: Re: [Springframework-user] Introduction and Hibernate-Spring 
> >> queries 
> >> 
> >> 
> >>> 
> >>> Throwing in Spring as middle tier glue is a good idea, of course :-) 
> >>> Have you already thought about my proposal regarding XWork/Spring 
> >>> integration from some days ago? Finally, we're of course open for any 
> >>> suggestions and enhancement requests on the Spring side of things! 
> >>> 
> >> 
> >> I this proposal in the public space.  I would also like to see 
> >> XW/WW2-Spring integration in the near term future. 
> >> 
> >> 
> >> Cheers, 
> >>    matthew 
> >> 
> > 
> > 
> > 
> > ------------------------------------------------------- 
> > This SF.net email is sponsored by: SF.net Giveback Program. 
> > SourceForge.net hosts over 70,000 Open Source Projects. 
> > See the people who have HELPED US provide better services: 
> > Click here: http://sourceforge.net/supporters.php
> > _______________________________________________ 
> > Springframework-developer mailing list 
> > Spr...@li... 
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> NHY޵隊X'u䅝CvϮ+j`ʋGRxZ+޶+)~zt
> xƤy(nbvvuޱ~ܶ*'jX)brH^mqzݢv{)~{
> +ׯzZ)zXX*kxŠuޖ^X(~zwilqzlX)ߣ))~{
> +ׯzZ)

[Springframework-developer] Mailing list black hole

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

Black hole might not be the most appropriate term (messages are getting 
out eventually), but there have been some seriously large delays in 
delivering messages to the lists during the last week.

I wrote the message below 3 days ago, and it only appeared in my inbox 
now...



Colin Sampaleanu wrote:

> Matthew E. Porter wrote:
>
>> On Wednesday, October 22, 2003, at 10:18 AM, Colin Sampaleanu wrote:
>>
>>> Matthew E. Porter wrote:
>>>
>>>> Greetings.  I am testing the Spring framework with a WW2+Hibernate 
>>>> web application currently being developed.  When initially 
>>>> deploying this application, the deployer is prompted with settings 
>>>> to configure the database settings- specifically, the Hibernate 
>>>> settings.  At that point, the hibernate.cfg.xml is written and 
>>>> Hibernate is loaded.
>>>>
>>>> From what I can tell, Spring prefers this information being written 
>>>> in the applicationContext.xml file and is tied to the entire 
>>>> container.  What is the best method for accomplishing something 
>>>> similar?
>>>
>>>
>>> Actually Spring (LocalSessionFactoryBean for example) has no problem 
>>> using hibernate.cfg.xml as a source for settings. There are indeed 
>>> lifecycle issues in your usage scenario though.
>>>
>>> The container normally creates singleton beans immediately (that is, 
>>> when the container loads), so that normally LocalSessionFactoryBean 
>>> would be created at that time, and would need it's parameters 
>>> (whether or not some data is coming from an external 
>>> hibernate.cfg.xml file is irrelevant).
>>
>>
>> That was my experience; however, being a newbie to Spring, I wanted 
>> confirmation.
>>
>>> How is the deployer prompted for the params that are needed? Is this 
>>> done only on the first usage after a new deploy?
>>
>>
>> The deployer is prompted for the settings when the initially access 
>> the application in the browser.  It should only been once, right 
>> after a new deploy.
>>
>> Do you see a way to work around this?
>
>
> That's a bit of a toughie. (Spring aside, changing something like a 
> datasource which is bound to JNDI is going to be hard to do in any 
> J2EE container environment, since the J2EE container is actually 
> setting up that datasource).
>
> One approach which might be made to work would be to assemble the 
> Spring context from multiple XML files (this capability is currently 
> available in CVS, the 1.0M1 release can only do nested contexts, which 
> are not quite the same thing). So the app would start up using a 
> context which didn't include the info needed to be configured (but 
> which presumably isn't needed for prompting the deployer, either), 
> prompt the deployer for the information, then write out the proper 
> Spring context xml file which needs to be customized. Then the app 
> would restart itself, and build the context from all the xml files 
> including the one that had been written.
>
> The mehanism of how to do a restart bit is somewhat iffy, in that it 
> would probably have to be servlet container specific, that is, you 
> would restart the webapp in a container specific fashion.
>
> Your alternative of course, is to do the configuration as part of the 
> deployment process, which is what most people do.
>
> Regards,
> Colin

[Springframework-developer] RE: RE: Class file manipulation with BCEL safe?

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

Mark Pollack wrote:
> I think the "side" file approach is also valid...it really tends to be a
> matter of taste. I believe the JSR175 committe also debated long and
> hard about where to put the attributes and ended up putting it in the
> bytecode.
> 
> I'm curious if CGLIB would behave the way suggested.

I'm pretty sure it would ;-)

> Java already stores
> a custom attribute in the bytecode, the 'depreacted' attribute. CGLIB
> might strip this out as well. It needs some investigation, I'll look
> into it. If it does strip out attributes there are probably implications
> for jdk1.5 based code.

It's more of a function of the underlying ASM library that CGLIB uses. In
its current incarnation it does not pass along attribute info when reading
a class, so there is no way for the data to make it into the generated
class. You are right that this will have to change in order to support the
JDK 1.5 stuff. I've been meaning to get into this issue soon.

> The side-file approach does feel better to people, those who typically
> dislike anything touching their bytecode and it does mean you don't have
> to copy the bcel.jar into ANT_HOME/lib, so it feels more lightweight.

When ASM has attribute support added, I think it could be appropriate to
have a JSR175-compatible metadata compiler as part of CGLIB, so if you're
using Spring you wouldn't have any additional dependencies (currently
CGLIB+ASM is less than half the size of BCEL alone).

Chris

[Springframework-developer] Re: XWork/Spring integration

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

SGkgTWF0dGhldywgDQoNCkkgc3VnZ2VzdCB0byBhZGQgdGhlICJleHRlcm5hbC1yZWYiIHRhZyB0
byB0aGUgWFdvcmsgWE1MIGZpbGUgaXRzZWxmLCBqdXN0IGxpa2UgdGhlIGV4aXN0aW5nICJwYXJh
bSIgdGFnLiBUaGlzIGlzIGJhc2ljYWxseSBhbiBpbnZlcnNpb24gb2YgdGhlIGN1cnJlbnQgWFdv
cmsgY29tcG9uZW50IGFwcHJvYWNoIC0tICJwdWxsaW5nIiBpbiBuYW1lZCBjb21wb25lbnQgaW5z
dGFuY2VzIGluc3RlYWQgb2YgInB1c2hpbmciIHRoZW0gdG8gdGhlIGFjdGlvbnMuDQoNCiAgPGFj
dGlvbiBuYW1lPSJCYXIiIGNsYXNzPSJteXBhY2thZ2UuTXlBY3Rpb24iPiANCiAgICAgPHBhcmFt
IG5hbWU9ImZvbyI+MTc8L3BhcmFtPiANCiAgICAgPGV4dGVybmFsLXJlZiBuYW1lPSJiYXIiPm15
RGF0YVNvdXJjZTwvZXh0ZXJuYWwtcmVmPiANCiAgPC9hY3Rpb24+IA0KDQpUaGUgTXlBY3Rpb24g
Y2xhc3MgY291bGQgbG9vayBhcyBmb2xsb3dzLiBOb3RlIHRoYXQgdGhlcmUncyBubyBlbmFibGVy
IGludGVyZmFjZSBpbnZvbHZlZDsgdGhlIGJlYW4gcHJvcGVydHkgYW5kIHRodXMgdGhlIHNldHRl
ciBpcyBkZXRlcm1pbmVkIHZpYSBleHRlcm5hbC1yZWbCtHMgIm5hbWUiIGF0dHJpYnV0ZSwganVz
dCBsaWtlIHdpdGggdGhlIHBhcmFtIHRhZy4NCg0KICBwdWJsaWMgY2xhc3MgTXlBY3Rpb24gaW1w
bGVtZW50cyBBY3Rpb24geyANCiAgICBwcml2YXRlIERhdGFTb3VyY2UgZGF0YVNvdXJjZTsgDQog
ICAgcHVibGljIHZvaWQgc2V0RGF0YVNvdXJjZShEYXRhU291cmNlIGRhdGFTb3VyY2UpIHsgDQog
ICAgICB0aGlzLmRhdGFTb3VyY2UgPSBkYXRhU291cmNlOyANCiAgICB9IA0KICAgIC4uLiANCiAg
fSANCg0KQXMgdGhpcyBpbnZvbHZlcyBzdXBwb3J0IGluIHRoZSBYV29yayBYTUwgZmlsZSwgdGhl
IFhXb3JrIGFjdGlvbiBwcm9jZXNzb3Igd2lsbCBuZWVkIHRvIGltcGxlbWVudCB0aGUgZXh0ZXJu
YWwtcmVmIHJlc29sdXRpb24gaXRzZWxmIGluc3RlYWQgb2YgYW4gaW50ZXJjZXB0b3IgbGlrZSBD
b21wb25lbnRJbnRlcmNlcHRvci4gSXQgY291bGQgZGVsZWdhdGUgdGhlIGFjdHVhbCByZXNvbHV0
aW9uIHRvIGFuIEV4dGVybmFsUmVmZXJlbmNlUmVzb2x2ZXIgc3RyYXRlZ3k6DQoNCiAgcHVibGlj
IGludGVyZmFjZSBFeHRlcm5hbFJlZmVyZW5jZVJlc29sdmVyIHsgDQogICAgT2JqZWN0IHJlc29s
dmVSZWZlcmVuY2UoU3RyaW5nIG5hbWUpOyANCiAgfSANCg0KSW4gY2FzZSBvZiBXZWJXb3JrMiBi
ZWluZyB0aGUgWFdvcmsgZW52aXJvbm1lbnQsIFNlcnZsZXREaXNwYXRjaGVyIGNvdWxkIGRldGVy
bWluZSB0aGUgRXh0ZXJuYWxSZWZlcmVuY2VSZXNvbHZlciBpbXBsZW1lbnRhdGlvbiBjbGFzcyBu
YW1lIGZyb20gYSBzZXJ2bGV0IGluaXQtcGFyYW0uIFRoZSBTcHJpbmcgaW1wbGVtZW50YXRpb24g
Zm9yIGEgd2ViIGVudmlyb25tZW50IHdvdWxkIHNpbXBseSByZXRyaWV2ZSB0aGUgcm9vdCB3ZWIg
YXBwbGljYXRpb24gY29udGV4dCB2aWEgdGhlIFNlcnZsZXRDb250ZXh0IHRoZW4sIHBvc3NpYmx5
IHJlY2VpdmluZyB0aGUgbGF0dGVyIHZpYSBhIFNlcnZsZXRDb250ZXh0QXdhcmUgaW50ZXJmYWNl
Lg0KDQogIHB1YmxpYyBjbGFzcyBTcHJpbmdTZXJ2bGV0Q29udGV4dFJlZmVyZW5jZVJlc29sdmVy
IGltcGxlbWVudHMgRXh0ZXJuYWxSZWZlcmVuY2VSZXNvbHZlciwgU2VydmxldENvbnRleHRBd2Fy
ZSB7IA0KICAgIHByaXZhdGUgdm9pZCBBcHBsaWNhdGlvbkNvbnRleHQgYXBwbGljYXRpb25Db250
ZXh0OyANCiAgICBwdWJsaWMgdm9pZCBzZXRTZXJ2bGV0Q29udGV4dChTZXJ2bGV0Q29udGV4dCBz
ZXJ2bGV0Q29udGV4dCkgeyANCiAgICAgIHRoaXMuYXBwbGljYXRpb25Db250ZXh0ID0gV2ViQXBw
bGljYXRpb25Db250ZXh0VXRpbHMuZ2V0V2ViQXBwbGljYXRpb25Db250ZXh0KHNlcnZsZXRDb250
ZXh0KTsgDQogICAgfSANCiAgICBwdWJsaWMgT2JqZWN0IHJlc29sdmVSZWZlcmVuY2UoU3RyaW5n
IG5hbWUpIHsgDQogICAgICByZXR1cm4gdGhpcy5hcHBsaWNhdGlvbkNvbnRleHQuZ2V0QmVhbihu
YW1lKTsgDQogICAgfSANCiAgfSANCg0KVGhlIFNwcmluZyByb290IHdlYiBhcHBsaWNhdGlvbiBj
b250ZXh0IHdvdWxkIGJlIGxvYWRlZCBvbiBzdGFydHVwIHZpYSBTcHJpbmcncyBDb250ZXh0TG9h
ZGVyTGlzdGVuZXIsIGFzIHVzdWFsLiBTcHJpbmcvV2ViV29yazIgd2ViIGFwcHMgd291bGQgdGh1
cyBqdXN0IHVzZSBTcHJpbmcncyB0eXBpY2FsICJXRUItSU5GL2FwcGxpY2F0aW9uQ29udGV4dC54
bWwiIGZvciBkZWZpbmluZyBtaWRkbGUgdGllciByZXNvdXJjZXMgYW5kIGJ1c2luZXNzIG9iamVj
dHMgcGx1cyBYV29yaydzICJ4d29yay54bWwiIGZvciBkZWZpbmluZyB1c2UtY2FzZS1kcml2ZW4g
YWN0aW9ucy4gVGhlcmXCtHMgbm8gImNvbXBvbmVudHMueG1sIiBpbnZvbHZlZCwgZXhjZXB0IGlm
IHRoZSB3ZWIgYXBwIHVzZXMgWFdvcmsncyBzY29wZWQgY29tcG9uZW50cyBtZWNoYW5pc20gdG9v
LiBUaGF0IHdvdWxkIGtlZXAgY29uZmlndXJhdGlvbiBzaW1wbGUgYW5kIGNvbmNpc2UgZW5vdWdo
IGZvciB0eXBpY2FsIG5lZWRzLg0KDQpUaGUgU3ByaW5nIGFwcGxpY2F0aW9uIGNvbnRleHQgd2ls
bCBhbHdheXMgYmUgYW4gYXBwbGljYXRpb24tbGV2ZWwgc2luZ2xldG9uLiBJbiBhIFdlYldvcmsy
IGNvbWJvLCB0aGVyZSBhcmUgbm8gbmVzdGVkIGFwcGxpY2F0aW9uIGNvbnRleHRzIGZyb20gYSBT
cHJpbmcgd2ViIE1WQyBEaXNwYXRjaGVyU2VydmxldCBpbnZvbHZlZCAtLSBXZWJXb3JrMiBzZXJ2
ZXMgYXMgd2ViIE1WQyBmcmFtZXdvcmsgdGhlbi4gTm90ZSB0aGF0IGFuIGFwcGxpY2F0aW9uIGNv
bnRleHQgY2FuIGNyZWF0ZSBlaXRoZXIgc2luZ2xldG9uIGJlYW5zIG9yIG5ldyBpbnN0YW5jZXMg
ZnJvbSBhIHByb3RvdHlwZSwgY29uZmlndXJhYmxlIHZpYSB0aGUgYmVhbiBkZWZpbml0aW9uLiBU
aGUgZXh0ZXJuYWwgcmVmZXJlbmNlIG1lY2hhbmlzbSBhYm92ZSB3b3VsZCBub3QgbmVlZCB0byBi
ZSBjb25jZXJuZWQgd2l0aCB0aGF0IGRpc3RpbmN0aW9uLCBpdCBjb3VsZCB0cmFuc3BhcmVudGx5
IHdvcmsgd2l0aCBib3RoIGtpbmRzOyBidXQgdHlwaWNhbCBtaWRkbGUgdGllciBvYmplY3RzIGFy
ZSBhbG1vc3QgYWx3YXlzIHNpbmdsZXRvbnMgYW55d2F5Lg0KDQpBIG5vbi13ZWIgWFdvcmsgZGlz
cGF0Y2hlciBjb3VsZCBiZSBjb25maWd1cmVkIHdpdGggYSBkaWZmZXJlbnQgU3ByaW5nIHJlc29s
dmVyIGltcGxlbWVudGF0aW9uLCB1c2luZyBhIENsYXNzUGF0aFhtbEFwcGxpY2F0aW9uQ29udGV4
dCBpbnN0ZWFkIG9mIGEgcHJlbG9hZGVkIFhtbFdlYkFwcGxpY2F0aW9uQ29udGV4dC4gSXQgd291
bGQgbG9vayBmb3IgYW4gImFwcGxpY2F0aW9uQ29udGV4dC54bWwiIHJlc291cmNlIGluIHRoZSBy
b290IG9mIHRoZSBjbGFzcyBwYXRoLg0KDQogIHB1YmxpYyBjbGFzcyBTcHJpbmdDbGFzc1BhdGhS
ZWZlcmVuY2VSZXNvbHZlciBpbXBsZW1lbnRzIEV4dGVybmFsUmVmZXJlbmNlUmVzb2x2ZXIgeyAN
CiAgICBwcml2YXRlIHZvaWQgQXBwbGljYXRpb25Db250ZXh0IGFwcGxpY2F0aW9uQ29udGV4dDsg
DQogICAgcHVibGljIFNwcmluZ0NsYXNzUGF0aFJlZmVyZW5jZVJlc29sdmVyKCkgeyANCiAgICAg
IHRoaXMuYXBwbGljYXRpb25Db250ZXh0ID0gbmV3IENsYXNzUGF0aFhtbEFwcGxpY2F0aW9uQ29u
dGV4dCgiL2FwcGxpY2F0aW9uQ29udGV4dC54bWwiKTsgDQogICAgfSANCiAgICBwdWJsaWMgT2Jq
ZWN0IHJlc29sdmVSZWZlcmVuY2UoU3RyaW5nIG5hbWUpIHsgDQogICAgICByZXR1cm4gdGhpcy5h
cHBsaWNhdGlvbkNvbnRleHQuZ2V0QmVhbihuYW1lKTsgDQogICAgfSANCiAgfSANCg0KVGhlIHdo
b2xlIGNvbmNlcHQgaXMgcHJldHR5IG9ydGhvZ29uYWwgdG8gWFdvcmsncyBleGlzdGluZyBzY29w
ZWQgY29tcG9uZW50IGFwcHJvYWNoLiBGb3IgZXhhbXBsZSwgYSB3ZWJzaG9wIGNvdWxkIGxldmVy
YWdlIGFuIFhXb3JrIGNvbXBvbmVudCBmb3IgYSBzZXNzaW9uLXNjb3BlZCBzaG9wcGluZyBjYXJ0
ICphbmQqIFNwcmluZy1tYW5hZ2VkIGJ1c2luZXNzIG9iamVjdHMgZm9yIGxvYWRpbmcgcHJvZHVj
dCBpbmZvcm1hdGlvbiBhbmQgZm9yIHR1cm5pbmcgdGhhdCBzaG9wcGluZyBjYXJ0IGludG8gYSBw
ZXJzaXN0ZW50IG9yZGVyLg0KDQpCVFcsIGFuIGFkLWhvYyBzb2x1dGlvbiBmb3IgYWNjZXNzaW5n
IGEgU3ByaW5nIHJvb3Qgd2ViIGFwcGxpY2F0aW9uIGNvbnRleHQgZnJvbSBhIFdlYldvcmsgYWN0
aW9uIGNvdWxkIGJlIHRvIG1ha2UgdGhlIGFjdGlvbiBIdHRwU2VydmxldFJlcXVlc3RBd2FyZSBh
bmQgZG8gdGhlIGFwcGxpY2F0aW9uIGNvbnRleHQgbG9va3VwIG1hbnVhbGx5LiBUaGF0IHdvdWxk
IHdvcmsgd2l0aG91dCBzcGVjaWFsIHN1cHBvcnQsIGV2ZW4gb24gV2ViV29yazEuDQoNCiAgLi4u
IA0KICBTZXJ2bGV0Q29udGV4dCBzZXJ2bGV0Q29udGV4dCA9IHJlcXVlc3QuZ2V0U2Vzc2lvbigp
LmdldFNlcnZsZXRDb250ZXh0KCk7IA0KICBBcHBsaWNhdGlvbkNvbnRleHQgYXBwbGljYXRpb25D
b250ZXh0ID0gV2ViQXBwbGljYXRpb25Db250ZXh0VXRpbHMuZ2V0V2ViQXBwbGljYXRpb25Db250
ZXh0KHNlcnZsZXRDb250ZXh0KTsgDQogIE15QnVzaW5lc3NPYmplY3QgYnVzaW5lc3NPYmplY3Qg
PSAoTXlCdXNpbmVzc09iamVjdCkgYXBwbGljYXRpb25Db250ZXh0LmdldEJlYW4oIm15QnVzaW5l
c3NPYmplY3QiKTsgDQogIC4uLiANCg0KT2YgY291cnNlLCBhbiBleHRlcm5hbCByZWZlcmVuY2Ug
cmVzb2x2ZXIgc29sdXRpb24gd291bGQgYmUgd2F5IHByZWZlcmFibGUgYmVjYXVzZSBpdCBhbGxv
d3MgdGhlIGFjdGlvbnMgdG8gcmVjZWl2ZSByZWZlcmVuY2VzIHRvIGJ1c2luZXNzIG9iamVjdHMg
dmlhIHNpbXBsZSBiZWFuIHByb3BlcnR5IHNldHRlcnMgb2YgdGhlIGJ1c2luZXNzIG9iamVjdCB0
eXBlOyBubyBjdXN0b20gbG9va3VwIGNvZGUgYW5kIGVzcGVjaWFsbHkgbm8gd2ViIGRlcGVuZGVu
Y2llcyBpbiB0aGUgYWN0aW9ucyBuZWNlc3NhcnkuDQoNCldoYXQgZG8geW91IHRoaW5rPyBEbyB5
b3Ugc2VlIGEgZGlmZmVyZW50IG9wdGlvbiBmb3IgaW50ZWdyYXRpb24/IEknbSBub3Qga2VlbiBv
biBsZXR0aW5nIFNwcmluZyB0b3VjaCB0aGUgWFdvcmsgYWN0aW9uIGluc3RhbmNlcyBkaXJlY3Rs
eTsgdGhhdCB3b3VsZCBpbnZvbHZlIGRvdWJsZSBkZWZpbml0aW9ucyBpbiBib3RoIHh3b3JrLnht
bCBhbmQgYXBwbGljYXRpb25Db250ZXh0LnhtbC4gY29tcG9uZW50cy54bWwgaXNuJ3QgYSBnb29k
IGludGVncmF0aW9uIHBvaW50IGVpdGhlciwgYXMgaXQgd291bGQgaW52b2x2ZSBkb3VibGUgZGVm
aW5pdGlvbnMgdG9vLiBJIGJlbGlldmUgdGhhdCBteSBwcm9wb3NhbCBpcyBzdHJhaWdodGZvcndh
cmQgYW5kIGludHVpdGl2ZSwgYXMgaXQgYXBwbGllcyBhIHNpbWlsYXIgbm90YXRpb24gZm9yIGJv
dGggYWN0aW9uIHBhcmFtcyBhbmQgZXh0ZXJuYWwgcmVmZXJlbmNlcy4gT2YgY291cnNlLCBpdCBp
bnRyb2R1Y2VzIGEgbmV3IGNvbmNlcHQgdG8geHdvcmsueG1sIC0tIGJ1dCBJIGJlbGlldmUgYSBw
b3dlcmZ1bCBhbmQgZ2VuZXJpYyBvbmUuDQoNCkp1ZXJnZW4gDQoNCg0KLS0tLS1VcnNwcsO8bmds
aWNoZSBOYWNocmljaHQtLS0tLSANClZvbjogTWF0dGhldyBFLiBQb3J0ZXIgW21haWx0bzptYXR0
aGV3QG1ldGlzc2lhbi5jb21dIA0KR2VzZW5kZXQ6IEZyIDI0LjEwLjIwMDMgMjI6MjMgDQpBbjog
asO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSANCkNjOiANCkJldHJlZmY6IFJlOiBYV29yay9TcHJp
bmcgaW50ZWdyYXRpb24gDQoNCg0KSsO8ZXJnZW46IA0KICAgSSBtYXkgc3RhcnQgd29ya2luZyBv
biB0aGUgc3ByaW5nLXd3MiBpbnRlZ3JhdGlvbiB0aGlzIHdlZWtlbmQgaWYgSSANCmdldCBzb21l
IHRpbWUuICBJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgdGhpcyBwcm9wb3NhbCBhbmQgaG93
IHRoZSANCnN5c3RlbSB3aWxsIHdvcmsuICBQbGVhc2UgZm9yZ2l2ZSBtZSBpZiB0aGVzZSBxdWVz
dGlvbnMgc2VlbSANCnJ1ZGltZW50YXJ5LCBhcyBJIGFtIHN0aWxsIGxlYXJuaW5nIFNwcmluZy4g
DQogICBBcmUgeW91IHRhbGtpbmcgYWJvdXQgYWRkaW5nIHRoZSAiZXh0ZXJuYWwtcmVmIiB0YWcg
dG8gDQpjb21wb25lbnRzLnhtbD8gIEluIHRoaXMgY2FzZSwgSSB3b3VsZCBhc3N1bWUgaXQgd291
bGQgcmVwbGFjZSB0aGUgMyANCnNjb3BlIGNvbmNlcHQgaW4gWFcgd2l0aCBTcHJpbmcncyBhcHBs
aWNhdGlvbiBhbmQgV2ViLU1WQyBzY29wZS4gIE9yIGFtIA0KSSBqdXN0IHdyb25nPyAgSG93IHdv
dWxkIEFjdGlvbnMgYmUgd2lyZWQgaW4/IA0KDQoNCkNoZWVycywgDQogICBtYXR0aGV3IA0KDQpP
biBUaHVyc2RheSwgT2N0b2JlciA5LCAyMDAzLCBhdCAxMjoxNiBQTSwgasO8cmdlbiBow7ZsbGVy
IFt3ZXJrM0FUXSANCndyb3RlOiANCg0KPiBNYXR0aGV3LCBNaWtlLCANCj4gDQo+IEhtbW0sIEkn
bSBub3QgYWx3YXlzIHRvbyBrZWVuIGluIHRlcm1zIG9mIHBlcmNlcHRpb24uLi4gYW55d2F5OiBI
aSANCj4gTWF0dGhldywgSSBkb24ndCB0aGluayBJIGNhbiB0byB0ZWxsIHlvdSBhbnl0aGluZyBh
Ym91dCBDb25kdWN0b3IgdGhhdCANCj4geW91IHdvdWxkbid0IGFscmVhZHkga25vdyA7LSkgDQo+
IA0KPiBJbiB0ZXJtcyBvZiBlZmZvcnQsIEkgZXhwZWN0IG15IFhXb3JrIHByb3Bvc2FsIHRvIGJl
IHByZXR0eSANCj4gc3RyYWlnaHRmb3J3YXJkIHRvIGltcGxlbWVudDogSXQncyBiYXNpY2FsbHkg
anVzdCBhYm91dCBpbnRyb2R1Y2luZyANCj4gdGhlICJleHRlcm5hbC1yZWYiIHRhZyBhbmQgYW4g
IkV4dGVybmFsUmVmZXJlbmNlUmVzb2x2ZXIiIGludGVyZmFjZSANCj4gdGhhdCB0aGUgdGFnIGRl
bGVnYXRlcyB0by4gQSBTcHJpbmcgaW1wbGVtZW50YXRpb24gb2YgdGhhdCBpbnRlcmZhY2UgDQo+
IHNob3VsZCBiZSBlYXN5IHRvIGRvIHRvbzogTG9hZCB0aGUgYXBwbGljYXRpb24gY29udGV4dCBp
biBzb21lIGluaXQgDQo+IG1ldGhvZCwgYW5kIHJlc29sdmUgdGhlIHJlZmVyZW5jZXMgYXMgYmVh
biBuYW1lcyBpbiB0aGUgY29udGV4dC4gDQo+IA0KPiBUaGUgb25seSBpc3N1ZSBpcyB3aGVyZSB0
byBsb2FkIHRoZSBhcHBsaWNhdGlvbiBjb250ZXh0IGZyb206IElmIHRoaXMgDQo+IHNob3VsZCBi
ZSBwb3NzaWJsZSBmcm9tIHRoZSBXRUItSU5GIGRpcmVjdG9yeSwgd2Ugd291bGQgbmVlZCBhIA0K
PiByZWZlcmVuY2UgdG8gdGhlIFNlcnZsZXRDb250ZXh0IGluIHRoZSBTcHJpbmdSZWZlcmVuY2VS
ZXNvbHZlciANCj4gaW1wbGVtZW50YXRpb24uIEVsc2UsIHdlIGNvdWxkIHVzZSBDbGFzc1BhdGhY
bWxBcHBsaWNhdGlvbkNvbnRleHQgdG8gDQo+IGxvYWQgdGhlIFhNTCBmaWxlIGZyb20gdGhlIGNs
YXNzIHBhdGg6IFRoaXMgd291bGQgbm90IGludm9sdmUgYW55dGhpbmcgDQo+IHNwZWNpYWwgYXQg
YWxsLiANCj4gDQo+IFNvIGluIGZhY3QsIHRoZSBpbnRlcmZhY2Ugd291bGQgbmVlZCBhbiBpbml0
IG1ldGhvZDogDQo+IA0KPiAgIHB1YmxpYyBpbnRlcmZhY2UgRXh0ZXJuYWxSZWZlcmVuY2VSZXNv
bHZlciB7IA0KPiAgICAgdm9pZCBpbml0KCk7IA0KPiAgICAgT2JqZWN0IHJlc29sdmVSZWZlcmVu
Y2UoU3RyaW5nIG5hbWUpOyANCj4gICB9IA0KPiANCj4gQSBTcHJpbmcgaW1wbGVtZW50YXRpb24g
Y291bGQgbG9vayBhcyBmb2xsb3dzOiANCj4gDQo+ICAgcHVibGljIGNsYXNzIFNwcmluZ1JlZmVy
ZW5jZVJlc29sdmVyIGltcGxlbWVudHMgDQo+IEV4dGVybmFsUmVmZXJlbmNlUmVzb2x2ZXIgeyAN
Cj4gICAgIHByaXZhdGUgQXBwbGljYXRpb25Db250ZXh0IGFwcGxpY2F0aW9uQ29udGV4dDsgDQo+
ICAgICBwdWJsaWMgdm9pZCBpbml0KCkgeyANCj4gICAgICAgYXBwbGljYXRpb25Db250ZXh0ID0g
bmV3IA0KPiBDbGFzc1BhdGhYbWxBcHBsaWNhdGlvbkNvbnRleHQoIi9zcHJpbmctY29udGV4dC54
bWwiKTsgDQo+ICAgICB9IA0KPiAgICAgcHVibGljIE9iamVjdCByZXNvbHZlUmVmZXJlbmNlKFN0
cmluZyBuYW1lKSB7IA0KPiAgICAgICByZXR1cm4gYXBwbGljYXRpb25Db250ZXh0LmdldEJlYW4o
bmFtZSk7IA0KPiAgICAgfSANCj4gICB9IA0KPiANCj4gSXQgZG9lc24ndCBuZWVkIHRvIGJlIG1v
cmUgY29tcGxpY2F0ZWQgdGhhbiB0aGlzLiBXZSB3b3VsZCBqdXN0IG5lZWQgDQo+IHRvIGludHJv
ZHVjZSBzdWNoIGV4dGVybmFsIHJlZmVyZW5jZSBob29rcyBpbiBYV29yay4gSSBkbyBub3QgY29u
c2lkZXIgDQo+IGFuICJleHRlcm5hbC1yZWYiIHRhZyBhcyBtdWNoIGV4dHJhIFhNTDsgYW5kIGl0
J3MgZWFzeSB0byBzcGVjaWZ5IA0KPiByZWZlcmVuY2VzIHRvIHNwZWNpZmljIGJlYW4gaW5zdGFu
Y2VzIHdpdGggaXQuIFdoYXQgZG8geW91IHRoaW5rPyANCj4gDQo+IEp1ZXJnZW4gDQo+IA0KPiAN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQo+IEZyb206IGrDvHJnZW4gaMO2bGxlciBb
d2VyazNBVF0gDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA5LCAyMDAzIDY6MzMgUE0gDQo+
IFRvOiBNYXR0aGV3IEUuIFBvcnRlciANCj4gQ2M6IHNwcmluZ2ZyYW1ld29yay11c2VyQGxpc3Rz
LnNvdXJjZWZvcmdlLm5ldDsgDQo+IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291
cmNlZm9yZ2UubmV0IA0KPiBTdWJqZWN0OiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gUkU6
IFtTcHJpbmdmcmFtZXdvcmstdXNlcl0gDQo+IEludHJvZHVjdGlvbiBhbmQgSGliZXJuYXRlLVNw
cmluZyBxdWVyaWVzIA0KPiANCj4gDQo+IE5vdCB5ZXQuIE1heWJlIE1pa2UgY2FuIGNvbW1lbnQg
b24gYSB0aW1lZnJhbWUsIGFsdGhvdWdoIEphc29uIG1pZ2h0IA0KPiBiZSB0aGUgb25lIHRoYXQg
YWN0dWFsbHkgd29ya3Mgb24gaXQuIE5vdGUgdGhhdCB0aGlzIHBsYW4gaXMgbm90IGZpeGVkIA0K
PiBhdCBhbGw7IGN1cnJlbnRseSwgWFdvcmsgaGFzIGl0cyBvd24gZW5hYmxlLWludGVyZmFjZS1j
ZW50cmljIHNpbXBsZSANCj4gSW9DIHN1cHBvcnQuIEknbSBqdXN0ICJjb25zdWx0aW5nIiBvbiB0
aGlzIGlzc3VlOyBNaWtlLCBKYXNvbiwgYW5kIHRoZSANCj4gb3RoZXIgWFdvcmsgZ3V5cyB3aWxs
IGhhdmUgdG8gZGVjaWRlIG9uIHdoYXQgdG8gYWRvcHQgaW4gdGhlIGVuZC4gDQo+IA0KPiBKdWVy
Z2VuIA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KPiBGcm9tOiBNYXR0
aGV3IEUuIFBvcnRlciBbbWFpbHRvOm1hdHRoZXdAbWV0aXNzaWFuLmNvbV0gDQo+IFNlbnQ6IFRo
dXJzZGF5LCBPY3RvYmVyIDA5LCAyMDAzIDY6MzEgUE0gDQo+IFRvOiBqw7xyZ2VuIGjDtmxsZXIg
W3dlcmszQVRdIA0KPiBDYzogc3ByaW5nZnJhbWV3b3JrLXVzZXJAbGlzdHMuc291cmNlZm9yZ2Uu
bmV0OyANCj4gc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQg
DQo+IFN1YmplY3Q6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLXVzZXJdIEludHJvZHVjdGlvbiBhbmQg
SGliZXJuYXRlLVNwcmluZyANCj4gcXVlcmllcyANCj4gDQo+IA0KPiBIYXMgYW55IHdvcmsgKGku
ZS4gY29kZSkgYmVlbiBkb25lIG9uIHRoaXM/IA0KPiANCj4gDQo+IENoZWVycywgDQo+ICAgIG1h
dHRoZXcgDQo+IA0KPiBPbiBUaHVyc2RheSwgT2N0b2JlciA5LCAyMDAzLCBhdCAxMToxNSBBTSwg
asO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSANCj4gd3JvdGU6IA0KPiANCj4+IE1hdHRoZXcsIGV2
ZXJ5Ym9keSwgDQo+PiANCj4+IE15IFhXb3JrL1NwcmluZyBpbnRlZ3JhdGlvbiBwcm9wb3NhbCBp
cyBubyBzZWNyZXQgLS0gaGVyZSBpdCBpcywgY3V0IA0KPj4gZnJvbSBhIHJlY2VudCBtYWlsIHRv
IEphc29uIGFuZCBNaWtlLiBXZSd2ZSBiZWVuIGRpc2N1c3NpbmcgSW9DIA0KPj4gb3B0aW9ucyBm
b3IgWFdvcmsvQ29uZHVjdG9yIGZvciBxdWl0ZSBhIHdoaWxlLCBtYWlubHkgaW4gdGVybXMgb2Yg
DQo+PiBQaWNvQ29udGFpbmVyIHZzIFNwcmluZy4gDQo+PiANCj4+IDxxdW90ZT4gDQo+PiANCj4+
IEFzIGZhciBhcyBJIHNlZSwgdGhlIFhXb3JrIGNvbmZpZyBmaWxlIHN1cHBvcnRzIHNldHRpbmcg
YmVhbiANCj4+IHByb3BlcnRpZXMgYXMgcGFyYW1ldGVycyBvbiBhY3Rpb25zIGxpa2UgdGhpczog
DQo+PiANCj4+ICAgPGFjdGlvbiBuYW1lPSJCYXIiIGNsYXNzPSJjb20ub3BlbnN5bXBob255Lnh3
b3JrLlNpbXBsZUFjdGlvbiI+IA0KPj4gICAgIDxwYXJhbSBuYW1lPSJmb28iPjE3PC9wYXJhbT4g
DQo+PiAgICAgPHBhcmFtIG5hbWU9ImJhciI+MjM8L3BhcmFtPiANCj4+ICAgPC9hY3Rpb24+IA0K
Pj4gDQo+PiBUaGlzIGlzIG9idmlvdXNseSBwcmV0dHkgc2ltaWxhciB0byBhIFNwcmluZyBiZWFu
IGRlZmluaXRpb24sIGp1c3QgDQo+PiBzcGVjaWZpYyBmb3IgYSBXZWJXb3JrIGFjdGlvbi4gQSBz
aWduaWZpY2FudCBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlIA0KPj4gU3ByaW5nIHByb3BlcnR5IHRh
ZyBjYW4gdGFnIGVpdGhlciBhIHZhbHVlIHRhZyBvciBhIHJlZiB0YWcgd2l0aGluLCANCj4+IGku
ZS4gZWl0aGVyIHNwZWNpZnkgYSBwYXJhbWV0ZXIgdmFsdWUgb3IgYcK0ZGVwZW5kZW5jeSBvbiBh
bm90aGVyIGJlYW4uIA0KPj4gDQo+PiBDdXJyZW50bHksIEkgc2VlIHRoZSBlYXNpZXN0IHdheSBv
ZiBhY2Nlc3NpbmcgYSBTcHJpbmcgY29udGV4dCBmcm9tIA0KPj4gWFdvcmsgdmlhIGEgdGFnIHRo
YXQgcmVzb2x2ZXMgYW4gZXh0ZXJuYWwgY29tcG9uZW50IHJlZmVyZW5jZSwgYSBsYTogDQo+PiAN
Cj4+ICAgPGFjdGlvbiBuYW1lPSJCYXIiIGNsYXNzPSJjb20ub3BlbnN5bXBob255Lnh3b3JrLlNp
bXBsZUFjdGlvbiI+IA0KPj4gICAgIDxwYXJhbSBuYW1lPSJmb28iPjE3PC9wYXJhbT4gDQo+PiAg
ICAgPGV4dGVybmFsLXJlZiBuYW1lPSJiYXIiPm15RGF0YVNvdXJjZTwvZXh0ZXJuYWwtcmVmPiAN
Cj4+ICAgPC9hY3Rpb24+IA0KPj4gDQo+PiBYV29yayBjb3VsZCBmZXRjaCB0aGUgU3ByaW5nIGNv
bnRleHQgdGhlbiwgbG9vayB1cCB0aGUgYmVhbiBuYW1lZCANCj4+ICJteURhdGFTb3VyY2UiLCBh
bmQgc2V0IHRoZSByZWZlcmVuY2UgaW50byB0aGUgImJhciIgYmVhbiBwcm9wZXJ0eSBvZiANCj4+
IHRoZSAiQmFyIiBhY3Rpb24uIFRoaXMgd291bGQgYmUgaW50dWl0aXZlLCBhcyBpdCB3b3JrcyBh
bmFsb2dvdXNseSB0byANCj4+IHNldHRpbmcgYSBwYXJhbWV0ZXIgdmFsdWUsIGFuZCBmbGV4aWJs
ZSwgYXMgaXQgYWxsb3dzIHRvIHJlZmVyZW5jZSBhbnkgDQo+PiBzcGVjaWZpYyBpbnN0YW5jZS4g
RWZmZWN0aXZlbHksIHlvdSB3b3VsZCBiZSBhY2Nlc3NpbmcgYmVhbnMgaW4gYSANCj4+IFNwcmlu
ZyBtaWRkbGUgdGllciBjb250ZXh0IHJhdGhlciB0aGFuIGxldHRpbmcgU3ByaW5nIHRvdWNoIHlv
dXIgDQo+PiBhY3Rpb24gaW5zdGFuY2VzIC0gYnV0IHRoYXQncyBub3QgYSBkaXNhZHZhbnRhZ2Us
IHJhdGhlciBhIGNsZWFuIA0KPj4gc2VwYXJhdGlvbiBvZiByZXNwb25zaWJpbGl0aWVzLiANCj4+
IA0KPj4gT2YgY291cnNlLCB0aGUgU3ByaW5nIHN1cHBvcnQgZm9yIHN1Y2ggZXh0ZXJuYWwgcmVm
ZXJlbmNlcyBjYW4gYmUgDQo+PiBwbHVnZ2FibGUgaW4gWFdvcmssIHBvdGVudGlhbGx5IHJlcGxh
Y2luZyB0aGUgY3VycmVudCBDb21wb25lbnRNYW5hZ2VyIA0KPj4gbWVjaGFuaXNtIHdpdGggaXRz
IGVuYWJsZXIgaW50ZXJmYWNlcy4gQW55IHN1Y2ggcmVzb2x2ZXIgZm9yIGV4dGVybmFsIA0KPj4g
cmVmZXJlbmNlcyB3b3VsZCBzaW1wbHkgbmVlZCB0byByZXR1cm4gYW4gb2JqZWN0IGZvciB0aGUg
Z2l2ZW4gDQo+PiBzeW1ib2xpYyBuYW1lLiBUaGUgaW50ZXJmYWNlIGNvdWxkIGxvb2sgbGlrZSB0
aGlzOiANCj4+IA0KPj4gICBwdWJsaWMgaW50ZXJmYWNlIEV4dGVybmFsUmVmZXJlbmNlUmVzb2x2
ZXIgeyANCj4+ICAgICBPYmplY3QgcmVzb2x2ZVJlZmVyZW5jZShTdHJpbmcgbmFtZSk7IA0KPj4g
ICB9IA0KPj4gDQo+PiBBIFNwcmluZyBpbXBsZW1lbnRhdGlvbiB3b3VsZCBncmFiIGEgcmVmZXJl
bmNlIHRvIHRoZSBTcHJpbmcgDQo+PiBhcHBsaWNhdGlvbiBjb250ZXh0IGFuZCBjYWxsIGdldEJl
YW4gd2l0aCB0aGUgZ2l2ZW4gbmFtZS4gVGhlIA0KPj4gYXBwbGljYXRpb24gY29udGV4dCBpdHNl
bGYgY291bGQgZ2V0IGluaXRpYWxpemVkIG9uIFhXb3JrIHN0YXJ0dXAsIA0KPj4gaW5pdGlhbGl6
aW5nIGl0cyBzaW5nbGV0b25zIHVwZnJvbnQuIEkgY29uc2lkZXIgc3VjaCBhbiBYV29yay9TcHJp
bmcgDQo+PiBpbnRlZ3JhdGlvbiBhcyBwcmV0dHkgc2ltcGxlIGJ1dCB2ZXJ5IHBvd2VyZnVsOiBu
byBlbmFibGVyIGludGVyZmFjZXMsIA0KPj4ganVzdCBiZWFuIHByb3BlcnRpZXMgd2l0aCBjb21w
b25lbnQgdHlwZXMsIGFuZCBhbiBleHRlcm5hbC1yZWYgdGFnIGluIA0KPj4gYWRkaXRpb24gdG8g
dGhlIHBhcmFtIHRhZy4gDQo+PiANCj4+IDwvcXVvdGU+IA0KPj4gDQo+PiBKdWVyZ2VuIA0KPj4g
DQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KPj4gRnJvbTogTWF0dGhldyBF
LiBQb3J0ZXIgW21haWx0bzptYXR0aGV3QG1ldGlzc2lhbi5jb21dIA0KPj4gU2VudDogVGh1cnNk
YXksIE9jdG9iZXIgMDksIDIwMDMgNDoxNiBQTSANCj4+IFRvOiBqw7xyZ2VuIGjDtmxsZXIgW3dl
cmszQVRdIA0KPj4gU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstdXNlcl0gSW50cm9kdWN0
aW9uIGFuZCBIaWJlcm5hdGUtU3ByaW5nIA0KPj4gcXVlcmllcyANCj4+IA0KPj4gDQo+Pj4gDQo+
Pj4gVGhyb3dpbmcgaW4gU3ByaW5nIGFzIG1pZGRsZSB0aWVyIGdsdWUgaXMgYSBnb29kIGlkZWEs
IG9mIGNvdXJzZSA6LSkgDQo+Pj4gSGF2ZSB5b3UgYWxyZWFkeSB0aG91Z2h0IGFib3V0IG15IHBy
b3Bvc2FsIHJlZ2FyZGluZyBYV29yay9TcHJpbmcgDQo+Pj4gaW50ZWdyYXRpb24gZnJvbSBzb21l
IGRheXMgYWdvPyBGaW5hbGx5LCB3ZSdyZSBvZiBjb3Vyc2Ugb3BlbiBmb3IgYW55IA0KPj4+IHN1
Z2dlc3Rpb25zIGFuZCBlbmhhbmNlbWVudCByZXF1ZXN0cyBvbiB0aGUgU3ByaW5nIHNpZGUgb2Yg
dGhpbmdzISANCj4+PiANCj4+IA0KPj4gSSB0aGlzIHByb3Bvc2FsIGluIHRoZSBwdWJsaWMgc3Bh
Y2UuICBJIHdvdWxkIGFsc28gbGlrZSB0byBzZWUgDQo+PiBYVy9XVzItU3ByaW5nIGludGVncmF0
aW9uIGluIHRoZSBuZWFyIHRlcm0gZnV0dXJlLiANCj4+IA0KPj4gDQo+PiBDaGVlcnMsIA0KPj4g
ICAgbWF0dGhldyANCj4+IA0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KPiBUaGlzIFNGLm5ldCBlbWFpbCBpcyBz
cG9uc29yZWQgYnk6IFNGLm5ldCBHaXZlYmFjayBQcm9ncmFtLiANCj4gU291cmNlRm9yZ2UubmV0
IGhvc3RzIG92ZXIgNzAsMDAwIE9wZW4gU291cmNlIFByb2plY3RzLiANCj4gU2VlIHRoZSBwZW9w
bGUgd2hvIGhhdmUgSEVMUEVEIFVTIHByb3ZpZGUgYmV0dGVyIHNlcnZpY2VzOiANCj4gQ2xpY2sg
aGVyZTogaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9zdXBwb3J0ZXJzLnBocCANCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQo+IFNwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0IA0KPiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxp
c3RzLnNvdXJjZWZvcmdlLm5ldCANCj4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlz
dHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciANCg0K

[Springframework-developer] Re: [springframework - Help] Index properties in forms

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

Juergen,

I think we should provide indexed property support for M3.  I think you were
right to remove the inadequate support for now.

I think supporting the Commons syntax makes sense. I think at one point I
envisaged having an IndexedPropertyValue class, but that's probably
unnecessary.

Regards,
Rod

-----Original Message-----
From: jürgen höller [werk3AT]
Sent: Thursday, October 23, 2003 4:50 PM
To: spr...@li...
Subject: FW: [springframework - Help] Index properties in forms


Everybody,

Seems like we've got two people inquiring for indexed property support. The
second already dates back to mid-September :-(

I've just rechecked the BeanWrapper implementation and discovered that there
is no proper support for indexed properties yet. The existing
getIndexedProperty method was not complete (e.g. no support for nesting) and
untested (no unit test covered it), so I've decided to remove it for the
time being (for 1.0 M2). It just confused both of those guys that were
looking for indexed property support.

Jakarta Commons BeanUtils does support nested and mapped properties, quoting
from the javadocs of their PropertyUtils class:

<quote>
For the purposes of this class, five formats for referencing a particular
property value of a bean are defined, with the layout of an identifying
String in parentheses:

* Simple (name) - The specified name identifies an individual property of a
particular JavaBean. The name of the actual getter or setter method to be
used is determined using standard JavaBeans instrospection, so that (unless
overridden by a BeanInfo class, a property named "xyz" will have a getter
method named getXyz() or (for boolean properties only) isXyz(), and a setter
method named setXyz().

* Nested (name1.name2.name3) The first name element is used to select a
property getter, as for simple references above. The object returned for
this property is then consulted, using the same approach, for a property
getter for a property named name2, and so on. The property value that is
ultimately retrieved or modified is the one identified by the last name
element.

* Indexed (name[index]) - The underlying property value is assumed to be an
array, or this JavaBean is assumed to have indexed property getter and
setter methods. The appropriate (zero-relative) entry in the array is
selected. List objects are now also supported for read/write. You simply
need to define a getter that returns the List

* Mapped (name(key)) - The JavaBean is assumed to have an property getter
and setter methods with an additional attribute of type java.lang.String.

* Combined (name1.name2[index].name3(key)) - Combining mapped, nested, and
indexed references is also supported
</quote>

The question is: When and how to we add support for indexed and mapped
properties? I guess that if we do, we should adopt the Commons BeanUtils
style of specifying property paths for index and map access. This means that
we wouldn't need additional methods in the BeanWrapper interface but rather
just support for respective property paths in the BeanWrapperImpl
implementation.

Any thoughts on this? I've completely forgotten about these things in face
of all the enterprise stuff we've been addressing lately ;-)

Juergen


https://sourceforge.net/forum/message.php?msg_id=2251775
By: breidenr

I am using a SimpleFormController to help create an object using an HTTP
form.
Obviously, if my form object is a Vendor, that object has a setName(String)
method, and my HTTP form has a field named "name", the Controller will try
call
Vendor.setName(String) and pass in the value from the form. This also goes
for
nested properties: address.setCity -> vendor.getAddress().setCity(String).

My question is, is there any support for *indexed* properties? By that, I
mean
purchaseOrder[0].number -> ( (PurchaseOrder)
vendor.getPurchaseOrders().get(0)).setNumber(). I know that some expression
languages support something like this. IIRC, Struts has something like this,
but it has a little kludgy.

From what I can tell, nested porperies are supported by the Spring
BeanWrapperImpl,
but that is it. If this is correct and I want to implement nested
properties,
any suggestion as to the best route.

Thanks.

Ryan



Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=2193984
By: hogie

Hi,



If I have a command object that stores a collection and I want the data
binder
to populate that collection from the servlet request, how should I name the
parameters in my servlet request?


In Struts I can do field[index], but I can't see if the same is possible in
Spring.  I see BeanWrapper.getIndexedPropertyValue() , but no set()
equivalent.


Many thanks,

Mike.

Re: [Springframework-developer] FW: [springframework - Help] Index properties in forms

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

Actually OGNL has no dependencies on any servlet classes. It's designed 
specifically to be embeeded in other products/libs.

The size and the fact that you are adding another dependency is 
obviously an issue though. Any way you slice it though, you are going to 
end up adding code to add the same functionality. In this respect, I am 
starting to be more of a fan of getting something pluggable in there. 
Perhaps it could use a quasi namespace prefix to pick the 
implementation, e.g.:
   ognl:expression
   anotherel:expression
   expression        (default implementation?)

Regards,
Colin


jürgen höller [werk3AT] wrote:

>Peter,
>
>I tend to agree that JSP EL syntax is preferable, although we are not talking about a web-specific thing here. We have to build this into BeanWrapperImpl in any case, as we need to do lookups of custom property editors etc to provide the same level of functionality as for current nested properties. I doubt that we could reuse any existing EL implementation for this, as they all work on a JSP PageContext. Generally, we should try to avoid any additional dependencies for the core bean factory.
>
>Juergen
>
>
>-----Original Message-----
>From: Peter den Haan [mailto:pe...@de...]
>Sent: Friday, October 24, 2003 1:25 AM
>To: spr...@li...
>Subject: [[W3-SPAM]] - Re: [Springframework-developer] FW:
>[springframework - Help] Index properties in forms - Email found in
>subject
>
>
>
>Juergen wrote:
>
>  
>
>>The question is: When and how to we add support for indexed and mapped
>>    
>>
>properties?
>  
>
>>I guess that if we do, we should adopt the Commons BeanUtils style of
>>    
>>
>specifying property
>  
>
>>paths for index and map access.
>>    
>>
>
>I disagree. I feel we should use (a subset of) the JSTL Expression Language
>(EL) syntax as our starting point rather than BeanUtils style syntax. Please
>consider that this EL will be part of JSP itself as of version 2.0 of the
>spec; why introduce another language into the mix? If in a JSP you say
>${foo.bar}, shouldn't you be able to name the corresponding field foo.bar
>rather than foo(bar)?
>
>For simple and indexed properties, users won't notice any difference anyway.
>The most important differences are that the precise meaning of a[b] is
>determined by whether "a" evaluates to a List or a Map, and that a.b is
>fully equivalent to a["b"]. BeanUtils-style mapped properties (i.e. a(b))
>aren't part of the EL; they could be supported in a compatible way but IMHO
>stick with core JavaBeans stuff -- do this only if we can come up with a
>compelling use case for it.
>
>And if this is being refactored anyway, it's probably worth taking a look at
>what would be involved in making the EL implementation pluggable.
>
> - Peter
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: The SF.net Donation Program.
>Do you like what SourceForge.net is doing for the Open
>Source Community?  Make a contribution, and help us add new
>features and functionality. Click here: http://sourceforge.net/donate/
>  
>

Re: [Springframework-developer] StaticMethodPointcut

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

+1

Rod Johnson wrote:

>Guys,
>
>I think we should change the signature on the StaticMethodPointcut applies()
>method to introduce a new argument, targetClass, as below:
>
>boolean applies(Method method, Class targetClass, AttributeRegistry
>attributeRegistry);
>
>The reason is that sometimes we need to know not just the method, but the
>target class we're invoking.
>
>Consider the getAge() method on class TestBean. A subclass, SpecialTestBean
>adds a class-level metadata attribute that should cause auto-proxying. With
>the old signature, the method argument would be TestBean.getAge() and
>without knowledge of the target class we would miss this important
>attribute.
>
>Does everyone agree this makes sense? Is there a better solution?
>
>This will break existing static pointcuts, although it's trivial to fix.
>I've already revised the source and test tree (although not committed yet).
>Hence I didn't commit it before M2.
>
>Regards,
>Rod
>  
>