springframework-developer — Spring Framework developers list

[Springframework-developer] Spring build.57 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] JavaMailSenderImpl bug/issue

[Vladimir O. <VO...@ci...>]

Hi, everyone.
=20
I ran into a weird bug/issue with JavaMailSenderImpl. The
JavaMailSenderImpl.doSend(MimeMessage[], Object[]) has the following
piece of code:
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
   Transport transport =3D getTransport(getSession());
   transport.connect(getHost(), getPort(), getUsername(),
getPassword());
   try {
    for (int i =3D 0; i < mimeMessages.length; i++) {
     MimeMessage mimeMessage =3D mimeMessages[i];
     try {
      if (mimeMessage.getSentDate() =3D=3D null) {
       mimeMessage.setSentDate(new Date());
      }
      mimeMessage.saveChanges();
      transport.sendMessage(mimeMessage,
mimeMessage.getAllRecipients());
     }
     catch (MessagingException ex) {
      Object original =3D (originalMessages !=3D null ? =
originalMessages[i]
: mimeMessage);
      failedMessages.put(original, ex);
     }
    }
   }
   finally {
    transport.close();
   }
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
The problem occurs when the message you are sending contains
non-existent attachments (as 'MimeBodyPart' of MimeMultipart object).
When that happens, 'transport' is getting completely disconnected for
some reason and the next message from MimeMessage array fails with
non-MessageException type exception, so the 'for' loop terminates
prematuraly. That is the operation fails because of 'Not Connected'
exception and the real cause for exception is completely hidden from the
user. Don't have the stack trace with me right now unfortunatelly.
=20
I assume it's a bug in Sun's JavaMail package, but it's quite easy to
put a generic fix into Spring code (so, that it won't be that dependent
on the bugs in the underlying libraries). Putting 'connected' inside the
for loop would be sufficient and does fix the problem.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
   Transport transport =3D getTransport(getSession());
   try {
    for (int i =3D 0; i < mimeMessages.length; i++) {
     if (!transport.connected())
       transport.connect(getHost(), getPort(), getUsername(),
getPassword());
     MimeMessage mimeMessage =3D mimeMessages[i];
     try {
      if (mimeMessage.getSentDate() =3D=3D null) {
       mimeMessage.setSentDate(new Date());
      }
      mimeMessage.saveChanges();
      transport.sendMessage(mimeMessage,
mimeMessage.getAllRecipients());
     }
     catch (MessagingException ex) {
      Object original =3D (originalMessages !=3D null ? =
originalMessages[i]
: mimeMessage);
      failedMessages.put(original, ex);
     }
    }
   }
   finally {
    transport.close();
   }
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
Thanks.
=20
Vlad
=20
PS: I'm using Spring 1.2.6.

[Springframework-developer] Spring build.56 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

[Springframework-developer] Spring build.55 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5

[Matt S. <mat...@sp...>]

I understand the reasoning, and I am glad to see Spring is being more 
aggressive in how lazily things are initialized.  I just wanted to point 
out a place where documentation could use some clarification.

I was indeed putting in false as the last argument to avoid eager 
initialization of FactoryBeans.  In particular, if true was passed in 
instead of false, that meant if I called getBeansOfType or 
getBeanNamesForType from a BeanFactoryPostProcessor, it would 
prematurely cause the initialization of FactoryBeans and therefore 
prevent other BeanFactoryPostProcessors from applying to those 
FactoryBeans.  So far I haven't run into any roadblocks because of this 
change, but I'll certainly let you know if I do :)  It may be the case 
that a fourth argument is needed to specify whether or not to search 
lazy-init objects separately from whether to search FactoryBeans for 
this reason, but I have not yet run into such a use case.

Migration has been pretty smooth for me, except that the Quartz 
SchedulerFactoryBean does not seem to like being proxied anymore.
http://opensource.atlassian.com/projects/spring/browse/SPR-2169

Matt

Juergen Hoeller wrote:
> Indeed... although I wonder why you passed in "false" as the last argument
> there in the first place. After all, the main reason to pass "false" in
> there was to avoid eager initialization of FactoryBeans...
> 
> For a significant portion of typical Spring apps, this shouldn't make much
> difference (at least I hope so), since the intent of the original flag is
> still somewhat similar to the new semantics.
> 
> Still, point taken - we need to clearly document this. It is a change in
> semantics for applications that either rely on default-lazy-init for all
> beans or make use of the getBeansOfType variant with "false" as last
> argument.
> 
> Unfortunately, there was no other way to provide the desired behavior for
> lazy loading of bean classes. The main goal was to not have standard
> getBeansOfType calls trigger the loading of all bean classes defined in the
> context.
> 
> Hope the migration was still smooth enough for you...
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Matt Sgarlata
> Sent: Wednesday, June 21, 2006 11:02 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Changed behavior
> fordefault-lazy-init="true" in 2.0 M5
> 
> This also changes the behavior of
> ListableBeanFactory.getBeansOfType(Class, boolean, false).  In Spring 1.x
> this method would return beans that had lazy-init="true" but in Spring 2.x
> this method does not reutrn beans with lazy-init="true".
> 
> This has been the largest source of migration headaches for me in my
> application.
> 
> Matt
> 
> Colin Sampaleanu wrote:
>> I think this makes sense, personally, although it does mean most apps 
>> marked with the default lazy init set to true will probably have to 
>> have their config tweaked. I guess we need to really emphasize this 
>> change in the change docs.
>>
>> Colin
>>
>> On 6/18/2006 7:40 PM, Juergen Hoeller wrote:
>>
>>> This is actually expected behavior: lazy-init has stronger effect in 
>>> Spring 2.0 now, not even loading the affected bean classes until they 
>>> are explicitly accessed.
>>>
>>> For an application context's type detection (such as 
>>> BeanFactoryPostProcessor detection or ApplicationListener detection), 
>>> we only check beans that allow for eager initialization now (i.e. 
>>> that are not marked as lazy-init and are not FactoryBeans).
>>>
>>> Else we'd have to load each and every bean class just to find out 
>>> those special beans, which would require all bean classes to be 
>>> present and loadable - and exactly that is what we intend to avoid 
>>> with the new semantics in the first place.
>>>
>>> A further goodie enabled by lazy class loading for lazy-init beans is 
>>> that a PropertyPlaceholderConfigurer can even resolve placeholders in 
>>> bean class names now, at least for beans marked as lazy-init.
>>>
>>> So the recommended solution in case of default-lazy-init=true would 
>>> be to explicitly mark all affected beans (the ones supposed to be 
>>> autodetected) as lazy-init=false.
>>>
>>> Juergen
>>>
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...] On 
>>> Behalf Of Claus Nordahl
>>> Sent: Sunday, June 11, 2006 2:26 AM
>>> To: spr...@li...
>>> Subject: [Springframework-developer] Changed behavior for 
>>> default-lazy-init="true" in 2.0 M5
>>>
>>> Hi all,
>>>
>>> When using default-lazy-init="true" with the 2.0 M5 release, I find 
>>> that neither does my PropertyPlaceholderConfigurer's do its stuff nor 
>>> does my ApplicationListener's receive any events as they all did with 
>>> previous releases.
>>>
>>> Is this expected behavior?
>>>
>>> Regards,
>>> Claus Nordahl
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Springframework-developer mailing list 
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>>> r
>>>
>>>
>>>
>>> _______________________________________________
>>> Springframework-developer mailing list 
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>>> r
>>>
>>>  
>>>
> 
> 
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5

[Juergen H. <ju...@in...>]

Indeed... although I wonder why you passed in "false" as the last argument
there in the first place. After all, the main reason to pass "false" in
there was to avoid eager initialization of FactoryBeans...

For a significant portion of typical Spring apps, this shouldn't make much
difference (at least I hope so), since the intent of the original flag is
still somewhat similar to the new semantics.

Still, point taken - we need to clearly document this. It is a change in
semantics for applications that either rely on default-lazy-init for all
beans or make use of the getBeansOfType variant with "false" as last
argument.

Unfortunately, there was no other way to provide the desired behavior for
lazy loading of bean classes. The main goal was to not have standard
getBeansOfType calls trigger the loading of all bean classes defined in the
context.

Hope the migration was still smooth enough for you...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Matt Sgarlata
Sent: Wednesday, June 21, 2006 11:02 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Changed behavior
fordefault-lazy-init="true" in 2.0 M5

This also changes the behavior of
ListableBeanFactory.getBeansOfType(Class, boolean, false).  In Spring 1.x
this method would return beans that had lazy-init="true" but in Spring 2.x
this method does not reutrn beans with lazy-init="true".

This has been the largest source of migration headaches for me in my
application.

Matt

Colin Sampaleanu wrote:
> I think this makes sense, personally, although it does mean most apps 
> marked with the default lazy init set to true will probably have to 
> have their config tweaked. I guess we need to really emphasize this 
> change in the change docs.
> 
> Colin
> 
> On 6/18/2006 7:40 PM, Juergen Hoeller wrote:
> 
>> This is actually expected behavior: lazy-init has stronger effect in 
>> Spring 2.0 now, not even loading the affected bean classes until they 
>> are explicitly accessed.
>>
>> For an application context's type detection (such as 
>> BeanFactoryPostProcessor detection or ApplicationListener detection), 
>> we only check beans that allow for eager initialization now (i.e. 
>> that are not marked as lazy-init and are not FactoryBeans).
>>
>> Else we'd have to load each and every bean class just to find out 
>> those special beans, which would require all bean classes to be 
>> present and loadable - and exactly that is what we intend to avoid 
>> with the new semantics in the first place.
>>
>> A further goodie enabled by lazy class loading for lazy-init beans is 
>> that a PropertyPlaceholderConfigurer can even resolve placeholders in 
>> bean class names now, at least for beans marked as lazy-init.
>>
>> So the recommended solution in case of default-lazy-init=true would 
>> be to explicitly mark all affected beans (the ones supposed to be 
>> autodetected) as lazy-init=false.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On 
>> Behalf Of Claus Nordahl
>> Sent: Sunday, June 11, 2006 2:26 AM
>> To: spr...@li...
>> Subject: [Springframework-developer] Changed behavior for 
>> default-lazy-init="true" in 2.0 M5
>>
>> Hi all,
>>
>> When using default-lazy-init="true" with the 2.0 M5 release, I find 
>> that neither does my PropertyPlaceholderConfigurer's do its stuff nor 
>> does my ApplicationListener's receive any events as they all did with 
>> previous releases.
>>
>> Is this expected behavior?
>>
>> Regards,
>> Claus Nordahl
>>
>>
>>
>>
>> _______________________________________________
>> Springframework-developer mailing list 
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>> r
>>
>>
>>
>> _______________________________________________
>> Springframework-developer mailing list 
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>> r
>>
>>  
>>


All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Changed behavior for default-lazy-init="true" in 2.0 M5

[Matt S. <mat...@sp...>]

This also changes the behavior of 
ListableBeanFactory.getBeansOfType(Class, boolean, false).  In Spring 
1.x this method would return beans that had lazy-init="true" but in 
Spring 2.x this method does not reutrn beans with lazy-init="true".

This has been the largest source of migration headaches for me in my 
application.

Matt

Colin Sampaleanu wrote:
> I think this makes sense, personally, although it does mean most apps 
> marked with the default lazy init set to true will probably have to have 
> their config tweaked. I guess we need to really emphasize this change in 
> the change docs.
> 
> Colin
> 
> On 6/18/2006 7:40 PM, Juergen Hoeller wrote:
> 
>> This is actually expected behavior: lazy-init has stronger effect in Spring
>> 2.0 now, not even loading the affected bean classes until they are
>> explicitly accessed.
>>
>> For an application context's type detection (such as
>> BeanFactoryPostProcessor detection or ApplicationListener detection), we
>> only check beans that allow for eager initialization now (i.e. that are not
>> marked as lazy-init and are not FactoryBeans).
>>
>> Else we'd have to load each and every bean class just to find out those
>> special beans, which would require all bean classes to be present and
>> loadable - and exactly that is what we intend to avoid with the new
>> semantics in the first place.
>>
>> A further goodie enabled by lazy class loading for lazy-init beans is that a
>> PropertyPlaceholderConfigurer can even resolve placeholders in bean class
>> names now, at least for beans marked as lazy-init.
>>
>> So the recommended solution in case of default-lazy-init=true would be to
>> explicitly mark all affected beans (the ones supposed to be autodetected) as
>> lazy-init=false.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On Behalf
>> Of Claus Nordahl
>> Sent: Sunday, June 11, 2006 2:26 AM
>> To: spr...@li...
>> Subject: [Springframework-developer] Changed behavior for
>> default-lazy-init="true" in 2.0 M5
>>
>> Hi all,
>>
>> When using default-lazy-init="true" with the 2.0 M5 release, I find that
>> neither does my PropertyPlaceholderConfigurer's do its stuff nor does my
>> ApplicationListener's receive any events as they all did with previous
>> releases.
>>
>> Is this expected behavior?
>>
>> Regards,
>> Claus Nordahl
>>
>>
>>
>>
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>  
>>

[Springframework-developer] Spring build.54 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] Spring Framework 2.0 RC1 released

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

I've updated the web site artifacts _except_ the release announcement 
itself, which Keith will handle...

On 6/20/2006 2:57 PM, Juergen Hoeller wrote:

>Dear Spring community,
>
>I'm pleased to announce that Spring 2.0 RC1 has been released. This is the
>first release candidate for Spring 2.0, after a series of five milestone
>releases. It is waiting for broad user feedback on its way towards 2.0
>final.
>
>The general topics for Spring 2.0 are simplified configuration and AOP
>unification, along with support for JPA, asynchronous JMS, and Portlet
>environments. Among the new features are:
>
>* Bean definitions based on XML schema, with out-of-the-box namespaces for
>common configuration tasks
>* Support for extended bean scopes in application contexts, with web request
>and session scopes as main targets
>* Bean definition enhancements: lazy loading of bean classes, collection
>merging, intelligent error messages
>
>* Simplified AOP configuration based on XML schema namespaces
>* Support for AspectJ pointcut expression language and AspectJ-style aspects
>* Support for dependency injection on any object (based on AspectJ)
>
>* Enhanced JDBC support: named SQL parameters, generics-based
>SimpleJdbcTemplate
>* Explicit support for Hibernate 3.1 and 3.2 (while remaining compatible
>with Hibernate 3.0)
>* Support for the Java Persistence API (JPA), including the full container
>contract (with class instrumentation)
>
>* TaskExecutor abstraction for submitting asynchronous work
>* Support for various thread pools, such as a Java 5 ThreadPoolExecutor and
>a CommonJ WorkManager
>* Support for asynchronous JMS ("Message-Driven POJOs"), based on message
>listener containers
>
>* Conventions-based web MVC: controller mappings, model attribute names
>* JSP form tag library for use with Spring Web MVC and Spring Web Flow
>* Full support for Portlet environments, including Portlet-style MVC based
>on a DispatcherPortlet
>
>And many, many refinements in the details...
>
>Enjoy!
>
>Cheers,
>
>Juergen
> 
>-----
>Juergen Hoeller
>Interface21
>http://www.springframework.com
>
>
>
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>

Re: [Springframework-developer] Is this code optimal from a performance standpoint?

[Solomon D. <sd...@gm...>]

Bob,

I invoked the entire code below a few times.  The first execution was slow,
but after that, the execution time was really quick (0-10 ms) using spring
2.0m5.

What's your goal with this test?

BTW,

I wrote a home-grown wrapper around the Spring classes which runs at roughly
the same speed.

The equivalent Java code is:

        ProgrammableConfigurer configurer = new ProgrammableConfigurer() {
            protected void configure() {
                // "foo" definition
                BeanConfiguration foo = prototype("foo", Foo.class);
                foo.property("i", 5).property("s", "test");
                foo.property("bar", ref("bar")).property("copy",
ref("bar"));

                // "bar" definition
                BeanConfiguration bar = prototype("bar", BarImpl.class);
                bar.constructor().generic(ref("tee")).generic(5);

                // "tee" definition
                BeanConfiguration tee = prototype("tee", TeeImpl.class);
                tee.constructor().generic("test");
            };
        };
        return (Foo) configurer.wire().getBean("foo");

-Solomon Duskis


On 6/19/06, Bob Lee <cra...@cr...> wrote:
>
> Or can I tweak it to make it faster?
>
>       DefaultListableBeanFactory beanFactory = new
> DefaultListableBeanFactory();
>
>       // "tee" definition
>       RootBeanDefinition tee = new RootBeanDefinition(TeeImpl.class,
> true);
>       tee.setLazyInit(true);
>       ConstructorArgumentValues teeValues = new
> ConstructorArgumentValues();
>       teeValues.addGenericArgumentValue("test");
>       tee.setConstructorArgumentValues(teeValues);
>
>       // "bar" definition
>       RootBeanDefinition bar = new RootBeanDefinition(BarImpl.class,
> false);
>       ConstructorArgumentValues barValues = new
> ConstructorArgumentValues();
>       barValues.addGenericArgumentValue(new RuntimeBeanReference("tee"));
>       barValues.addGenericArgumentValue(5);
>       bar.setConstructorArgumentValues(barValues);
>
>       // "foo" definition
>       RootBeanDefinition foo = new RootBeanDefinition(Foo.class, false);
>       MutablePropertyValues fooValues = new MutablePropertyValues();
>       fooValues.addPropertyValue("i", 5);
>       fooValues.addPropertyValue("bar", new RuntimeBeanReference("bar"));
>       fooValues.addPropertyValue("copy", new RuntimeBeanReference("bar"));
>       fooValues.addPropertyValue("s", "test");
>       foo.setPropertyValues(fooValues);
>
>       beanFactory.registerBeanDefinition("foo", foo);
>       beanFactory.registerBeanDefinition("bar", bar);
>       beanFactory.registerBeanDefinition("tee", tee);
>
>       Foo foo = (Foo) beanFactory.getBean("foo");
>
> Here are the types I'm wiring:
>
>   public class Foo {
>
>     Bar bar;
>     Bar copy;
>     String s;
>     int i;
>
>     public void setI(int i) {
>       this.i = i;
>     }
>
>     public void setBar(Bar bar) {
>       this.bar = bar;
>     }
>
>     public void setCopy(Bar copy) {
>       this.copy = copy;
>     }
>
>     public void setS(String s) {
>       this.s = s;
>     }
>   }
>
>   interface Bar {
>
>     Tee getTee();
>     int getI();
>   }
>
>   public class BarImpl implements Bar {
>
>     final int i;
>     final Tee tee;
>
>     public BarImpl(Tee tee, int i) {
>       this.tee = tee;
>       this.i = i;
>     }
>
>     public Tee getTee() {
>       return tee;
>     }
>
>     public int getI() {
>       return i;
>     }
>   }
>
>   interface Tee {
>
>     String getS();
>   }
>
>   public static class TeeImpl implements Tee {
>
>     final String s;
>
>     public TeeImpl(String s) {
>       this.s = s;
>     }
>
>     public String getS() {
>       return s;
>     }
>   }
>
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Spring build.53 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] [Springframework-user] Spring Framework 2.0 RC1 released

[Ben H. <be...@in...>]

Once the release is completely posted take a look at the reference  
documentation.  Both Chapter 14 (Web MVC Framework) and Appendix E  
(spring-form.tld) go into great depth about the tag lib.

Ben Hale
Spring Training, Consulting and Support - "From the Source"
http://www.interface21.com
cell: 321.591.2340



On Jun 20, 2006, at 3:29 PM, <Nic...@we...>  
<Nic...@we...> wrote:

> This may be too early since it's an RC....
>
> but can anyone point me to a link to the *JSP form tag library* in the
> new release.  Either documentation or the source.
>
> Thanks,
>
> Nick Neuberger
>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]
>> On Behalf Of Juergen Hoeller
>> Sent: Tuesday, June 20, 2006 1:58 PM
>> To: spr...@li...; 'List
>> for Spring users'
>> Subject: [Springframework-user] Spring Framework 2.0 RC1 released
>>
>> Dear Spring community,
>>
>> I'm pleased to announce that Spring 2.0 RC1 has been
>> released. This is the first release candidate for Spring 2.0,
>> after a series of five milestone releases. It is waiting for
>> broad user feedback on its way towards 2.0 final.
>>
>> The general topics for Spring 2.0 are simplified
>> configuration and AOP unification, along with support for
>> JPA, asynchronous JMS, and Portlet environments. Among the
>> new features are:
>>
>> * Bean definitions based on XML schema, with out-of-the-box
>> namespaces for common configuration tasks
>> * Support for extended bean scopes in application contexts,
>> with web request and session scopes as main targets
>> * Bean definition enhancements: lazy loading of bean classes,
>> collection merging, intelligent error messages
>>
>> * Simplified AOP configuration based on XML schema namespaces
>> * Support for AspectJ pointcut expression language and
>> AspectJ-style aspects
>> * Support for dependency injection on any object (based on AspectJ)
>>
>> * Enhanced JDBC support: named SQL parameters, generics-based
>> SimpleJdbcTemplate
>> * Explicit support for Hibernate 3.1 and 3.2 (while remaining
>> compatible with Hibernate 3.0)
>> * Support for the Java Persistence API (JPA), including the
>> full container contract (with class instrumentation)
>>
>> * TaskExecutor abstraction for submitting asynchronous work
>> * Support for various thread pools, such as a Java 5
>> ThreadPoolExecutor and a CommonJ WorkManager
>> * Support for asynchronous JMS ("Message-Driven POJOs"),
>> based on message listener containers
>>
>> * Conventions-based web MVC: controller mappings, model
>> attribute names
>> * JSP form tag library for use with Spring Web MVC and Spring Web  
>> Flow
>> * Full support for Portlet environments, including
>> Portlet-style MVC based on a DispatcherPortlet
>>
>> And many, many refinements in the details...
>>
>> Enjoy!
>>
>> Cheers,
>>
>> Juergen
>>
>> -----
>> Juergen Hoeller
>> Interface21
>> http://www.springframework.com
>>
>>
>>
>> _______________________________________________
>> Springframework-user mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-user
>>
>
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] [Springframework-user] Spring Framework 2.0 RC1 released

[<Nic...@we...>]

This may be too early since it's an RC....

but can anyone point me to a link to the *JSP form tag library* in the
new release.  Either documentation or the source.
=20
Thanks,

Nick Neuberger

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]=20
> On Behalf Of Juergen Hoeller
> Sent: Tuesday, June 20, 2006 1:58 PM
> To: spr...@li...; 'List=20
> for Spring users'
> Subject: [Springframework-user] Spring Framework 2.0 RC1 released
>=20
> Dear Spring community,
>=20
> I'm pleased to announce that Spring 2.0 RC1 has been=20
> released. This is the first release candidate for Spring 2.0,=20
> after a series of five milestone releases. It is waiting for=20
> broad user feedback on its way towards 2.0 final.
>=20
> The general topics for Spring 2.0 are simplified=20
> configuration and AOP unification, along with support for=20
> JPA, asynchronous JMS, and Portlet environments. Among the=20
> new features are:
>=20
> * Bean definitions based on XML schema, with out-of-the-box=20
> namespaces for common configuration tasks
> * Support for extended bean scopes in application contexts,=20
> with web request and session scopes as main targets
> * Bean definition enhancements: lazy loading of bean classes,=20
> collection merging, intelligent error messages
>=20
> * Simplified AOP configuration based on XML schema namespaces
> * Support for AspectJ pointcut expression language and=20
> AspectJ-style aspects
> * Support for dependency injection on any object (based on AspectJ)
>=20
> * Enhanced JDBC support: named SQL parameters, generics-based=20
> SimpleJdbcTemplate
> * Explicit support for Hibernate 3.1 and 3.2 (while remaining=20
> compatible with Hibernate 3.0)
> * Support for the Java Persistence API (JPA), including the=20
> full container contract (with class instrumentation)
>=20
> * TaskExecutor abstraction for submitting asynchronous work
> * Support for various thread pools, such as a Java 5=20
> ThreadPoolExecutor and a CommonJ WorkManager
> * Support for asynchronous JMS ("Message-Driven POJOs"),=20
> based on message listener containers
>=20
> * Conventions-based web MVC: controller mappings, model=20
> attribute names
> * JSP form tag library for use with Spring Web MVC and Spring Web Flow
> * Full support for Portlet environments, including=20
> Portlet-style MVC based on a DispatcherPortlet
>=20
> And many, many refinements in the details...
>=20
> Enjoy!
>=20
> Cheers,
>=20
> Juergen
> =20
> -----
> Juergen Hoeller
> Interface21
> http://www.springframework.com
>=20
>=20
>=20
> _______________________________________________
> Springframework-user mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-user
>=20

[Springframework-developer] Spring Framework 2.0 RC1 released

[Juergen H. <ju...@in...>]

Dear Spring community,

I'm pleased to announce that Spring 2.0 RC1 has been released. This is the
first release candidate for Spring 2.0, after a series of five milestone
releases. It is waiting for broad user feedback on its way towards 2.0
final.

The general topics for Spring 2.0 are simplified configuration and AOP
unification, along with support for JPA, asynchronous JMS, and Portlet
environments. Among the new features are:

* Bean definitions based on XML schema, with out-of-the-box namespaces for
common configuration tasks
* Support for extended bean scopes in application contexts, with web request
and session scopes as main targets
* Bean definition enhancements: lazy loading of bean classes, collection
merging, intelligent error messages

* Simplified AOP configuration based on XML schema namespaces
* Support for AspectJ pointcut expression language and AspectJ-style aspects
* Support for dependency injection on any object (based on AspectJ)

* Enhanced JDBC support: named SQL parameters, generics-based
SimpleJdbcTemplate
* Explicit support for Hibernate 3.1 and 3.2 (while remaining compatible
with Hibernate 3.0)
* Support for the Java Persistence API (JPA), including the full container
contract (with class instrumentation)

* TaskExecutor abstraction for submitting asynchronous work
* Support for various thread pools, such as a Java 5 ThreadPoolExecutor and
a CommonJ WorkManager
* Support for asynchronous JMS ("Message-Driven POJOs"), based on message
listener containers

* Conventions-based web MVC: controller mappings, model attribute names
* JSP form tag library for use with Spring Web MVC and Spring Web Flow
* Full support for Portlet environments, including Portlet-style MVC based
on a DispatcherPortlet

And many, many refinements in the details...

Enjoy!

Cheers,

Juergen
 
-----
Juergen Hoeller
Interface21
http://www.springframework.com

Re: [Springframework-developer] Spring 2.0 M4 vs. M5

[Juergen H. <ju...@in...>]

To make sure I'm not misunderstood there: We're gonna provide both - one
all-encompassing jar plus a set of fine-grained jars, just like we did for
Spring 1.2. The standard download gives you all of those jars in one box.

The only difference to M4 is that spring.jar now includes everything again
(like in Spring 1.2) rather than just most of it. The provided fine-grained
jars sit alongside that big spring.jar, as out-of-the-box alternative.

Juergen 


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Juergen Hoeller
Sent: Tuesday, June 20, 2006 9:51 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 2.0 M4 vs. M5

Hi Matt,

We tried a number of different jar file arrangements and eventually went
with the all-encompassing spring.jar for 2.0 M5, as alternative to a
combination of  fine-grained jars from the "modules" directory. The mock jar
is still separate, sitting alongside either spring.jar or a combination of
fine-grained jars. The same applies to the jar that contains the AspectJ
aspects.

The line between what's within spring.jar and what's a separate jar was just
becoming too arbitrary, with the various O/R Mapping options on the one hand
and the various web integration options on the other hand. Hence, the
current plan is so stick with the "one-big-jar versus
many-fine-grained-jars" strategy for 2.0 RC1 and final again (just like we
had it in Spring 1.2.x).

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Matt Raible
Sent: Tuesday, June 20, 2006 12:59 AM
To: spr...@li...
Subject: [Springframework-developer] Spring 2.0 M4 vs. M5

The spring.jar for 2.0 M4 didn't include org.springframework.orm.hibernate*.
The one for M5 does.  The spring-hibernate3.jar for M4 included Hibernate
dependencies (in the Maven POM), the one for M5 does not.  Which is the
correct way moving forward?  Which way will it be in 2.0 Final?

Thanks,

Matt


_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Use .java file as scripted beans

[Nicolas De L. <nic...@ca...>]

>>> One interesting thing to note is that all valid Java
>>> programs are valid Groovy programs.
>>>       
>> I did not try groovy miself. Does this mean that I can open a .java  
>> file
>> using Spring groovy script support and get a bean ?
>>     
>
> It should - I haven't actually tried it but there should be no issues.

I've made a simple test : A simple Java source can be used succesfully 
as a groovy script and used as scripted bean.
This allows me to code on a running application !
As I use .java file from my Eclipse IDE, I have a natural restriction 
not to use groovy code not beeing java compatible, so I can use the same 
java source file as groovy bean in devs and as class in target 
(production) environment.

My test was very simple, so I don't know if groovy may run complex java 
files, but this looks a very exciting solution, with high productivity 
in mind.

That beeing said, it may be cleaner to have a "pure" java 
compiler/script engine to turn source java file into scripted-bean.

Nico.


This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.

[Springframework-developer] Spring build.52 SUCCEEDED

[<bu...@in...>]

Snapshot has been uploaded to http://www.springframework.org/snaphots
    			
The list of modifications for this build can be found in the build log (http://static.springframework.org/spring/build/index.html).    			
			

Re: [Springframework-developer] Use .java file as scripted beans

[Rob H. <ro...@in...>]

On 20 Jun 2006, at 09:39, Nicolas De Loof wrote:

>
>
> Rob Harrop a =E9crit :
>> This is something that Adrian and I have been discussing for some
>> time. In theory it is entirely possible, but we have all seen enough
>> horror at the hands of classloaders to know that it isnt entirely
>> trivial.
> Isn't Spring expected to make easy those non-trivial stuff  ;-)

Indeed! This is definitely something we are focused on.
>
>> One interesting thing to note is that all valid Java
>> programs are valid Groovy programs.
> I did not try groovy miself. Does this mean that I can open a .java =20=

> file
> using Spring groovy script support and get a bean ?

It should - I haven't actually tried it but there should be no issues.
>
>> Another area that may be of
>> interest to many people is the ability to embed the JDT compiler from
>> Eclipse to compile sources on the fly.
>>
>> In practice on the fly compilation for certain classes that are
>> hidden behind statically compiled interfaces is not tremendously
>> difficult. The issues arise when you start to talk about dynamically
>> compiling the entire application and arbitrarily replacing individual
>> pieces. This can result in some very interesting dependency issues.
>>
> I was expecting such restriction. I only consider the ability to =20
> change
> service code on the fly without repackaging / redeploying / restarting
> my webapp. I know jetty runner starts quicker than tomcat and =20
> Spring 2.0
> has better lazy-init support, but this only make this process quicker,
> not easier. Some of my process requires to follow a long flow in the
> webapp, and I need to repeat it on every code change. Hot-replacing =20=

> the
> service implementation code would make it trivial.

I'll see what I can do in the 2.1 timeframe for getting a JDT/Janino =20
based solution working.
>
> That beeing said, if you find a way to solve those
> classloading/compiling issues for replacing arbitrary code in a =20
> running
> app and hot-refactoring interfaces, you're welcome :-D
>
> I'll take a look at  Niklas suggestion about janino classloader.
> Thanks.
>
> Nico.
>
>> Rob
>>
>> On 20 Jun 2006, at 08:47, Niklas Therning wrote:
>>
>
> This message contains information that may be privileged or =20
> confidential and is the property of the Capgemini Group. It is =20
> intended only for the person to whom it is addressed. If you are =20
> not the intended recipient,  you are not authorized to read, print, =20=

> retain, copy, disseminate,  distribute, or use this message or any =20
> part thereof. If you receive this  message in error, please notify =20
> the sender immediately and delete all  copies of this message.
>
>
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

--=20
Rob Harrop
VP, Technology Strategy
Interface21 - Spring Services from the Source
http://www.springframework.com

Re: [Springframework-developer] Use .java file as scripted beans

[Nicolas De L. <nic...@ca...>]

Rob Harrop a =E9crit :
> This is something that Adrian and I have been discussing for some =20
> time. In theory it is entirely possible, but we have all seen enough =20
> horror at the hands of classloaders to know that it isnt entirely =20
> trivial.=20
Isn't Spring expected to make easy those non-trivial stuff  ;-)

> One interesting thing to note is that all valid Java =20
> programs are valid Groovy programs.=20
I did not try groovy miself. Does this mean that I can open a .java file=20
using Spring groovy script support and get a bean ?

> Another area that may be of =20
> interest to many people is the ability to embed the JDT compiler from =20
> Eclipse to compile sources on the fly.
>
> In practice on the fly compilation for certain classes that are =20
> hidden behind statically compiled interfaces is not tremendously =20
> difficult. The issues arise when you start to talk about dynamically =20
> compiling the entire application and arbitrarily replacing individual =20
> pieces. This can result in some very interesting dependency issues.
>  =20
I was expecting such restriction. I only consider the ability to change=20
service code on the fly without repackaging / redeploying / restarting=20
my webapp. I know jetty runner starts quicker than tomcat and Spring 2.0=20
has better lazy-init support, but this only make this process quicker,=20
not easier. Some of my process requires to follow a long flow in the=20
webapp, and I need to repeat it on every code change. Hot-replacing the=20
service implementation code would make it trivial.

That beeing said, if you find a way to solve those=20
classloading/compiling issues for replacing arbitrary code in a running=20
app and hot-refactoring interfaces, you're welcome :-D

I'll take a look at  Niklas suggestion about janino classloader.
Thanks.

Nico.

> Rob
>
> On 20 Jun 2006, at 08:47, Niklas Therning wrote:
>  =20

This message contains information that may be privileged or confidential =
and is the property of the Capgemini Group. It is intended only for the p=
erson to whom it is addressed. If you are not the intended recipient,  yo=
u are not authorized to read, print, retain, copy, disseminate,  distribu=
te, or use this message or any part thereof. If you receive this  message=
 in error, please notify the sender immediately and delete all  copies of=
 this message.

Re: [Springframework-developer] Use .java file as scripted beans

[Rob H. <ro...@in...>]

This is something that Adrian and I have been discussing for some  
time. In theory it is entirely possible, but we have all seen enough  
horror at the hands of classloaders to know that it isnt entirely  
trivial. One interesting thing to note is that all valid Java  
programs are valid Groovy programs. Another area that may be of  
interest to many people is the ability to embed the JDT compiler from  
Eclipse to compile sources on the fly.

In practice on the fly compilation for certain classes that are  
hidden behind statically compiled interfaces is not tremendously  
difficult. The issues arise when you start to talk about dynamically  
compiling the entire application and arbitrarily replacing individual  
pieces. This can result in some very interesting dependency issues.

Rob

On 20 Jun 2006, at 08:47, Niklas Therning wrote:

> Nicolas De Loof wrote:
>> Hello guys,
>>
>> I've looked at new script support and sounds great for quick  
>> design or
>> prototyping "edit source code, hit refresh and get the result",  
>> BUT it
>> requires to learn yet another langage.
>> I can agree that "grrovy is great" or "bsh is java like" or any other
>> enthousiastic comment on scripting languages, but my development team
>> has lots of junior java developers and my hierarchy has lot's of old
>> schools men that will make very difficult to accept a "script"  
>> language
>> as a valid technology.
>>
>> I'm looking for a way to code scripted spring beans as 100% Java  
>> source
>> code, using full IDE support, so that developer doesn't have to know
>> some class is used a scripted bean and some other as compiled  
>> code. My
>> first think comes to JSP that are runtime compiled (an re- 
>> compiled) by
>> the container. It would be great to have a similar support for  
>> java code
>> to be "runtime re-compilable". When the code gets fine, it can be
>> classicaly compiled into a .class and pakaged into the app, by simply
>> changing the spring context.
>>
>> Looking at the way tomcat (jasper) compiles JSP, it seems it uses a
>> custom classloader to load the runtime-compiled .class. My experience
>> with classloaders is limited so I can say if it would be easy, but  
>> here
>> is how I'd see this : a FactoryBean creates a proxy for the bean
>> interface and delegates invocation to a "runtime-compiled" class in a
>> child classloader. Hot recompilation requires the bean to be  
>> stateless,
>> but this sounds an aceptable constraint if I can code my web  
>> controlers
>> or business services by a quick code/test/code.
>>
>> Thanks for any suggestion to make this a reality.
>>
>> Nico.
>
> Janino, http://www.janino.net/, is a small footprint Java compiler.  
> It's
> mostly Java 1.4 compatible. Haven't used it myself yet but it looks
> interesting. It includes a classloader which loads classes directly  
> from
> Java sources, http://www.janino.net/use.html#class_loader.
>
> Regards,
> Niklas
>
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

-- 
Rob Harrop
VP, Technology Strategy
Interface21 - Spring Services from the Source
http://www.springframework.com

Re: [Springframework-developer] Spring 2.0 M4 vs. M5

[Juergen H. <ju...@in...>]

Hi Matt,

We tried a number of different jar file arrangements and eventually went
with the all-encompassing spring.jar for 2.0 M5, as alternative to a
combination of  fine-grained jars from the "modules" directory. The mock jar
is still separate, sitting alongside either spring.jar or a combination of
fine-grained jars. The same applies to the jar that contains the AspectJ
aspects.

The line between what's within spring.jar and what's a separate jar was just
becoming too arbitrary, with the various O/R Mapping options on the one hand
and the various web integration options on the other hand. Hence, the
current plan is so stick with the "one-big-jar versus
many-fine-grained-jars" strategy for 2.0 RC1 and final again (just like we
had it in Spring 1.2.x).

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Matt Raible
Sent: Tuesday, June 20, 2006 12:59 AM
To: spr...@li...
Subject: [Springframework-developer] Spring 2.0 M4 vs. M5

The spring.jar for 2.0 M4 didn't include org.springframework.orm.hibernate*.
The one for M5 does.  The spring-hibernate3.jar for M4 included Hibernate
dependencies (in the Maven POM), the one for M5 does not.  Which is the
correct way moving forward?  Which way will it be in 2.0 Final?

Thanks,

Matt


_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Use .java file as scripted beans

[Niklas T. <ni...@tr...>]

Nicolas De Loof wrote:
> Hello guys,
> 
> I've looked at new script support and sounds great for quick design or 
> prototyping "edit source code, hit refresh and get the result", BUT it 
> requires to learn yet another langage.
> I can agree that "grrovy is great" or "bsh is java like" or any other 
> enthousiastic comment on scripting languages, but my development team 
> has lots of junior java developers and my hierarchy has lot's of old 
> schools men that will make very difficult to accept a "script" language 
> as a valid technology.
> 
> I'm looking for a way to code scripted spring beans as 100% Java source 
> code, using full IDE support, so that developer doesn't have to know 
> some class is used a scripted bean and some other as compiled code. My 
> first think comes to JSP that are runtime compiled (an re-compiled) by 
> the container. It would be great to have a similar support for java code 
> to be "runtime re-compilable". When the code gets fine, it can be 
> classicaly compiled into a .class and pakaged into the app, by simply 
> changing the spring context.
> 
> Looking at the way tomcat (jasper) compiles JSP, it seems it uses a 
> custom classloader to load the runtime-compiled .class. My experience 
> with classloaders is limited so I can say if it would be easy, but here 
> is how I'd see this : a FactoryBean creates a proxy for the bean 
> interface and delegates invocation to a "runtime-compiled" class in a 
> child classloader. Hot recompilation requires the bean to be stateless, 
> but this sounds an aceptable constraint if I can code my web controlers 
> or business services by a quick code/test/code.
> 
> Thanks for any suggestion to make this a reality.
> 
> Nico.

Janino, http://www.janino.net/, is a small footprint Java compiler. It's 
mostly Java 1.4 compatible. Haven't used it myself yet but it looks 
interesting. It includes a classloader which loads classes directly from 
Java sources, http://www.janino.net/use.html#class_loader.

Regards,
Niklas

[Springframework-developer] Use .java file as scripted beans

[Nicolas De L. <nic...@ca...>]

Hello guys,

I've looked at new script support and sounds great for quick design or 
prototyping "edit source code, hit refresh and get the result", BUT it 
requires to learn yet another langage.
I can agree that "grrovy is great" or "bsh is java like" or any other 
enthousiastic comment on scripting languages, but my development team 
has lots of junior java developers and my hierarchy has lot's of old 
schools men that will make very difficult to accept a "script" language 
as a valid technology.

I'm looking for a way to code scripted spring beans as 100% Java source 
code, using full IDE support, so that developer doesn't have to know 
some class is used a scripted bean and some other as compiled code. My 
first think comes to JSP that are runtime compiled (an re-compiled) by 
the container. It would be great to have a similar support for java code 
to be "runtime re-compilable". When the code gets fine, it can be 
classicaly compiled into a .class and pakaged into the app, by simply 
changing the spring context.

Looking at the way tomcat (jasper) compiles JSP, it seems it uses a 
custom classloader to load the runtime-compiled .class. My experience 
with classloaders is limited so I can say if it would be easy, but here 
is how I'd see this : a FactoryBean creates a proxy for the bean 
interface and delegates invocation to a "runtime-compiled" class in a 
child classloader. Hot recompilation requires the bean to be stateless, 
but this sounds an aceptable constraint if I can code my web controlers 
or business services by a quick code/test/code.

Thanks for any suggestion to make this a reality.

Nico.



This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.

[Springframework-developer] Is this code optimal from a performance standpoint?

[Bob L. <cra...@cr...>]

Or can I tweak it to make it faster?

      DefaultListableBeanFactory beanFactory = new DefaultListableBeanFactory();

      // "tee" definition
      RootBeanDefinition tee = new RootBeanDefinition(TeeImpl.class, true);
      tee.setLazyInit(true);
      ConstructorArgumentValues teeValues = new ConstructorArgumentValues();
      teeValues.addGenericArgumentValue("test");
      tee.setConstructorArgumentValues(teeValues);

      // "bar" definition
      RootBeanDefinition bar = new RootBeanDefinition(BarImpl.class, false);
      ConstructorArgumentValues barValues = new ConstructorArgumentValues();
      barValues.addGenericArgumentValue(new RuntimeBeanReference("tee"));
      barValues.addGenericArgumentValue(5);
      bar.setConstructorArgumentValues(barValues);

      // "foo" definition
      RootBeanDefinition foo = new RootBeanDefinition(Foo.class, false);
      MutablePropertyValues fooValues = new MutablePropertyValues();
      fooValues.addPropertyValue("i", 5);
      fooValues.addPropertyValue("bar", new RuntimeBeanReference("bar"));
      fooValues.addPropertyValue("copy", new RuntimeBeanReference("bar"));
      fooValues.addPropertyValue("s", "test");
      foo.setPropertyValues(fooValues);

      beanFactory.registerBeanDefinition("foo", foo);
      beanFactory.registerBeanDefinition("bar", bar);
      beanFactory.registerBeanDefinition("tee", tee);

      Foo foo = (Foo) beanFactory.getBean("foo");

Here are the types I'm wiring:

  public class Foo {

    Bar bar;
    Bar copy;
    String s;
    int i;

    public void setI(int i) {
      this.i = i;
    }

    public void setBar(Bar bar) {
      this.bar = bar;
    }

    public void setCopy(Bar copy) {
      this.copy = copy;
    }

    public void setS(String s) {
      this.s = s;
    }
  }

  interface Bar {

    Tee getTee();
    int getI();
  }

  public class BarImpl implements Bar {

    final int i;
    final Tee tee;

    public BarImpl(Tee tee, int i) {
      this.tee = tee;
      this.i = i;
    }

    public Tee getTee() {
      return tee;
    }

    public int getI() {
      return i;
    }
  }

  interface Tee {

    String getS();
  }

  public static class TeeImpl implements Tee {

    final String s;

    public TeeImpl(String s) {
      this.s = s;
    }

    public String getS() {
      return s;
    }
  }

[Springframework-developer] Spring 2.0 M4 vs. M5

[Matt R. <mr...@gm...>]

The spring.jar for 2.0 M4 didn't include
org.springframework.orm.hibernate*.  The one for M5 does.  The
spring-hibernate3.jar for M4 included Hibernate dependencies (in the
Maven POM), the one for M5 does not.  Which is the correct way moving
forward?  Which way will it be in 2.0 Final?

Thanks,

Matt