springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Re: Preparing for 1.0.2

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

Tim,
=20
Thanks for spotting this - actually, all 2004 date entries in the =
changelog said 2003 - and noone noticed up to now... :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tim Nolan
Gesendet: So 23.05.2004 08:56
An: spr...@li...
Betreff: [Springframework-developer] Re: Preparing for 1.0.2



Just a small thing, change log date is 2003 instead of 2004. I think a
few of the date entries need fixing.


j=FCrgen h=F6ller [werk3AT] wrote:
> Hi everybody,
>=20
> I've just finished my final preparations for our upcoming Spring =
release 1.0.2, scheduled for Sunday night. See the changelog for =
details; most issues have been discussed on the mailing lists or in =
JIRA. All remaining issues in JIRA have been addressed but do not incur =
Spring changes; I plan to close most of them at the time of the 1.0.2 =
release, resolved as "Won't fix".
>=20
> I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate =
2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons =
Attributes May 9th snapshot. (Will Commons Attributes ever get out of =
the Jakarta sandbox?? At least some sort of official beta release would =
be nice.) BTW, MockObjects is no longer in our libraries, neither in CVS =
nor in the release distribution, as we don't use it anymore.
>=20
> I plan to create the actual release Sunday night. So for all you =
weekend workhorses out there, there's still a chance to test and review =
the current CVS head :-) Please no further enhancements, though: As the =
changelog shows, we've already gathered a lot of minor bugfixes and =
enhancements, so we should get out 1.0.2 ASAP. Further enhancements =
should go into 1.0.3, scheduled for late June.
>=20
> Juergen
>=20
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Preparing for 1.0.2

[Tim N. <kat...@ho...>]

Just a small thing, change log date is 2003 instead of 2004. I think a 
few of the date entries need fixing.


jürgen höller [werk3AT] wrote:
> Hi everybody,
>  
> I've just finished my final preparations for our upcoming Spring release 1.0.2, scheduled for Sunday night. See the changelog for details; most issues have been discussed on the mailing lists or in JIRA. All remaining issues in JIRA have been addressed but do not incur Spring changes; I plan to close most of them at the time of the 1.0.2 release, resolved as "Won't fix".
>  
> I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate 2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons Attributes May 9th snapshot. (Will Commons Attributes ever get out of the Jakarta sandbox?? At least some sort of official beta release would be nice.) BTW, MockObjects is no longer in our libraries, neither in CVS nor in the release distribution, as we don't use it anymore.
>  
> I plan to create the actual release Sunday night. So for all you weekend workhorses out there, there's still a chance to test and review the current CVS head :-) Please no further enhancements, though: As the changelog shows, we've already gathered a lot of minor bugfixes and enhancements, so we should get out 1.0.2 ASAP. Further enhancements should go into 1.0.3, scheduled for late June.
>  
> Juergen
>  
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id66&op=click

Re: [Springframework-developer] Spring IDE with eclipse M9

[Thomas R. <tho...@tr...>]

Cameron,

It's already available - and it works well - see my comment on this thread

http://sourceforge.net/forum/message.php?msg_id=2581562

Thomas



Cameron Braid wrote:

> As many of you may know, Eclipse 3.0 M9 is out, and they don’t supply 
> the xerces plugin anymore.
>
> Are there plans for a new release of the Spring IDE that will work 
> with M9 ?
>
> Thanks,
>
> Cameron
>

[Springframework-developer] Spring IDE with eclipse M9

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

As many of  you may know, Eclipse 3.0 M9 is out, and they don't supply the
xerces plugin anymore.

 

Are there plans for a new release of the Spring IDE that will work with M9 ?

 

Thanks,

 

Cameron

Re: [Springframework-developer] Preparing for 1.0.2

[Thomas R. <tho...@tr...>]

Colin Sampaleanu wrote:

> The latest versions of Eclipse seem to essentially try to walk the 
> entire dependency tree of the code in your project, presumably so you 
> get better code comprehension when you look at hierarchies and the like.
>
> I have added the JCA 1.5 api jar to make it happy.

I'm happy too now :-)

>
>
> By the way, and Eclipse users not using 3.0 M9 should give it a try. 
> I've been using the 3.0 stream since about M3, but the last month or 
> so they've really done a lot of tuning and little tweaks all over the 
> place in terms of usability and look and feel.
>
I have to agree - this looks like a very solid release so far.  And the 
Spring IDE does already support it.

Thomas

> Colin
>
>
> Dmitriy Kopylenko wrote:
>
>> There is a resource adapter implementation of SessionFactory in 
>> Hibernate namly net.sf.hibernate.jca.JCASessionFactoryImpl.
>>
>>
>> Thomas Risberg wrote:
>>
>>> It is orm.hibernate.SessionFactoryUtils - Eclipse claims that it is 
>>> indirectly referenced from required .class files.
>>>
>>> Thomas
>>>
>>>
>>> jürgen höller [werk3AT] wrote:
>>>
>>>> Doesn't j2ee.jar include the entire J2EE RI, rather than just the 
>>>> J2EE APIs? In any case, I prefer the individual jars, as they allow 
>>>> to pick individual API versions rather than a particular J2EE 
>>>> collective. They also allow application developers to pick just the 
>>>> API jars that they actually need to compile against.
>>>>
>>>> So if we need JCA for some odd reason, I vote for adding the 
>>>> individual jca.jar to our libs. However, I don' t know of any JCA 
>>>> dependency in our code... Everything compiled nicely on my machine 
>>>> - without JCA.
>>>>
>>>> Juergen
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> Von: spr...@li... im 
>>>> Auftrag von Thomas Risberg
>>>> Gesendet: Sa 22.05.2004 22:26
>>>> An: spr...@li...
>>>> Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>>>>
>>>>
>>>>
>>>> I get an error in Eclipse - can't find javax.resource.Referencable.
>>>> That's part of JCA I think and it does not seem to be in any of our 
>>>> j2ee
>>>> libs. Why don't we replace servlet.jar, ejb.jar, jdbc2_0-stdext.jar,
>>>> jms.jar and jta.jar with the full j2ee.jar. That way we have all the
>>>> dependencies resolved. What version? I tried 1.3 and with it 
>>>> everything
>>>> compiles. The new 1.4 seems to have some new methods in some of the
>>>> interfaces and some of our MockObject implementations did not compile.
>>>>
>>>> Thomas
>>>>
>>>> jürgen höller [werk3AT] wrote:
>>>>
>>>>  
>>>>
>>>>> Hi everybody,
>>>>>
>>>>> I've just finished my final preparations for our upcoming Spring 
>>>>> release 1.0.2, scheduled for Sunday night. See the changelog for 
>>>>> details; most issues have been discussed on the mailing lists or 
>>>>> in JIRA. All remaining issues in JIRA have been addressed but do 
>>>>> not incur Spring changes; I plan to close most of them at the time 
>>>>> of the 1.0.2 release, resolved as "Won't fix".
>>>>>
>>>>> I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate 
>>>>> 2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons 
>>>>> Attributes May 9th snapshot. (Will Commons Attributes ever get out 
>>>>> of the Jakarta sandbox?? At least some sort of official beta 
>>>>> release would be nice.) BTW, MockObjects is no longer in our 
>>>>> libraries, neither in CVS nor in the release distribution, as we 
>>>>> don't use it anymore.
>>>>>
>>>>> I plan to create the actual release Sunday night. So for all you 
>>>>> weekend workhorses out there, there's still a chance to test and 
>>>>> review the current CVS head :-) Please no further enhancements, 
>>>>> though: As the changelog shows, we've already gathered a lot of 
>>>>> minor bugfixes and enhancements, so we should get out 1.0.2 ASAP. 
>>>>> Further enhancements should go into 1.0.3, scheduled for late June.
>>>>>
>>>>> Juergen
>>>>
>>>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] Preparing for 1.0.2

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

The latest versions of Eclipse seem to essentially try to walk the 
entire dependency tree of the code in your project, presumably so you 
get better code comprehension when you look at hierarchies and the like.

I have added the JCA 1.5 api jar to make it happy.

By the way, and Eclipse users not using 3.0 M9 should give it a try. 
I've been using the 3.0 stream since about M3, but the last month or so 
they've really done a lot of tuning and little tweaks all over the place 
in terms of usability and look and feel.

Colin


Dmitriy Kopylenko wrote:

> There is a resource adapter implementation of SessionFactory in 
> Hibernate namly net.sf.hibernate.jca.JCASessionFactoryImpl.
>
>
> Thomas Risberg wrote:
>
>> It is orm.hibernate.SessionFactoryUtils - Eclipse claims that it is 
>> indirectly referenced from required .class files.
>>
>> Thomas
>>
>>
>> jürgen höller [werk3AT] wrote:
>>
>>> Doesn't j2ee.jar include the entire J2EE RI, rather than just the 
>>> J2EE APIs? In any case, I prefer the individual jars, as they allow 
>>> to pick individual API versions rather than a particular J2EE 
>>> collective. They also allow application developers to pick just the 
>>> API jars that they actually need to compile against.
>>>
>>> So if we need JCA for some odd reason, I vote for adding the 
>>> individual jca.jar to our libs. However, I don' t know of any JCA 
>>> dependency in our code... Everything compiled nicely on my machine - 
>>> without JCA.
>>>
>>> Juergen
>>>
>>>
>>> ________________________________
>>>
>>> Von: spr...@li... im 
>>> Auftrag von Thomas Risberg
>>> Gesendet: Sa 22.05.2004 22:26
>>> An: spr...@li...
>>> Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>>>
>>>
>>>
>>> I get an error in Eclipse - can't find javax.resource.Referencable.
>>> That's part of JCA I think and it does not seem to be in any of our 
>>> j2ee
>>> libs. Why don't we replace servlet.jar, ejb.jar, jdbc2_0-stdext.jar,
>>> jms.jar and jta.jar with the full j2ee.jar. That way we have all the
>>> dependencies resolved. What version? I tried 1.3 and with it everything
>>> compiles. The new 1.4 seems to have some new methods in some of the
>>> interfaces and some of our MockObject implementations did not compile.
>>>
>>> Thomas
>>>
>>> jürgen höller [werk3AT] wrote:
>>>
>>>  
>>>
>>>> Hi everybody,
>>>>
>>>> I've just finished my final preparations for our upcoming Spring 
>>>> release 1.0.2, scheduled for Sunday night. See the changelog for 
>>>> details; most issues have been discussed on the mailing lists or in 
>>>> JIRA. All remaining issues in JIRA have been addressed but do not 
>>>> incur Spring changes; I plan to close most of them at the time of 
>>>> the 1.0.2 release, resolved as "Won't fix".
>>>>
>>>> I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate 
>>>> 2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons 
>>>> Attributes May 9th snapshot. (Will Commons Attributes ever get out 
>>>> of the Jakarta sandbox?? At least some sort of official beta 
>>>> release would be nice.) BTW, MockObjects is no longer in our 
>>>> libraries, neither in CVS nor in the release distribution, as we 
>>>> don't use it anymore.
>>>>
>>>> I plan to create the actual release Sunday night. So for all you 
>>>> weekend workhorses out there, there's still a chance to test and 
>>>> review the current CVS head :-) Please no further enhancements, 
>>>> though: As the changelog shows, we've already gathered a lot of 
>>>> minor bugfixes and enhancements, so we should get out 1.0.2 ASAP. 
>>>> Further enhancements should go into 1.0.3, scheduled for late June.
>>>>
>>>> Juergen
>>>

Re: [Springframework-developer] Preparing for 1.0.2

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

There is a resource adapter implementation of SessionFactory in 
Hibernate namly net.sf.hibernate.jca.JCASessionFactoryImpl.


Thomas Risberg wrote:

> It is orm.hibernate.SessionFactoryUtils - Eclipse claims that it is 
> indirectly referenced from required .class files.
>
> Thomas
>
>
> jürgen höller [werk3AT] wrote:
>
>> Doesn't j2ee.jar include the entire J2EE RI, rather than just the 
>> J2EE APIs? In any case, I prefer the individual jars, as they allow 
>> to pick individual API versions rather than a particular J2EE 
>> collective. They also allow application developers to pick just the 
>> API jars that they actually need to compile against.
>>
>> So if we need JCA for some odd reason, I vote for adding the 
>> individual jca.jar to our libs. However, I don' t know of any JCA 
>> dependency in our code... Everything compiled nicely on my machine - 
>> without JCA.
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag 
>> von Thomas Risberg
>> Gesendet: Sa 22.05.2004 22:26
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>>
>>
>>
>> I get an error in Eclipse - can't find javax.resource.Referencable.
>> That's part of JCA I think and it does not seem to be in any of our j2ee
>> libs. Why don't we replace servlet.jar, ejb.jar, jdbc2_0-stdext.jar,
>> jms.jar and jta.jar with the full j2ee.jar. That way we have all the
>> dependencies resolved. What version? I tried 1.3 and with it everything
>> compiles. The new 1.4 seems to have some new methods in some of the
>> interfaces and some of our MockObject implementations did not compile.
>>
>> Thomas
>>
>> jürgen höller [werk3AT] wrote:
>>
>>  
>>
>>> Hi everybody,
>>>
>>> I've just finished my final preparations for our upcoming Spring 
>>> release 1.0.2, scheduled for Sunday night. See the changelog for 
>>> details; most issues have been discussed on the mailing lists or in 
>>> JIRA. All remaining issues in JIRA have been addressed but do not 
>>> incur Spring changes; I plan to close most of them at the time of 
>>> the 1.0.2 release, resolved as "Won't fix".
>>>
>>> I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate 
>>> 2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons 
>>> Attributes May 9th snapshot. (Will Commons Attributes ever get out 
>>> of the Jakarta sandbox?? At least some sort of official beta release 
>>> would be nice.) BTW, MockObjects is no longer in our libraries, 
>>> neither in CVS nor in the release distribution, as we don't use it 
>>> anymore.
>>>
>>> I plan to create the actual release Sunday night. So for all you 
>>> weekend workhorses out there, there's still a chance to test and 
>>> review the current CVS head :-) Please no further enhancements, 
>>> though: As the changelog shows, we've already gathered a lot of 
>>> minor bugfixes and enhancements, so we should get out 1.0.2 ASAP. 
>>> Further enhancements should go into 1.0.3, scheduled for late June.
>>>
>>> Juergen
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: Oracle 10g
>>> Get certified on the hottest thing ever to hit the market... Oracle 
>>> 10g.
>>> Take an Oracle 10g class now, and we'll give you the exam FREE.
>>> http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>
>>>   
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 10g.
>> Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>  
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.0.2

[Thomas R. <tho...@tr...>]

It is orm.hibernate.SessionFactoryUtils - Eclipse claims that it is 
indirectly referenced from required .class files.

Thomas


jürgen höller [werk3AT] wrote:

>Doesn't j2ee.jar include the entire J2EE RI, rather than just the J2EE APIs? In any case, I prefer the individual jars, as they allow to pick individual API versions rather than a particular J2EE collective. They also allow application developers to pick just the API jars that they actually need to compile against.
> 
>So if we need JCA for some odd reason, I vote for adding the individual jca.jar to our libs. However, 
>I don' t know of any JCA dependency in our code... Everything compiled nicely on my machine - without JCA.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Thomas Risberg
>Gesendet: Sa 22.05.2004 22:26
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Preparing for 1.0.2
>
>
>
>I get an error in Eclipse - can't find javax.resource.Referencable.
>That's part of JCA I think and it does not seem to be in any of our j2ee
>libs. Why don't we replace servlet.jar, ejb.jar, jdbc2_0-stdext.jar,
>jms.jar and jta.jar with the full j2ee.jar. That way we have all the
>dependencies resolved. What version? I tried 1.3 and with it everything
>compiles. The new 1.4 seems to have some new methods in some of the
>interfaces and some of our MockObject implementations did not compile.
>
>Thomas
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Hi everybody,
>>
>>I've just finished my final preparations for our upcoming Spring release 1.0.2, scheduled for Sunday night. See the changelog for details; most issues have been discussed on the mailing lists or in JIRA. All remaining issues in JIRA have been addressed but do not incur Spring changes; I plan to close most of them at the time of the 1.0.2 release, resolved as "Won't fix".
>>
>>I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate 2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons Attributes May 9th snapshot. (Will Commons Attributes ever get out of the Jakarta sandbox?? At least some sort of official beta release would be nice.) BTW, MockObjects is no longer in our libraries, neither in CVS nor in the release distribution, as we don't use it anymore.
>>
>>I plan to create the actual release Sunday night. So for all you weekend workhorses out there, there's still a chance to test and review the current CVS head :-) Please no further enhancements, though: As the changelog shows, we've already gathered a lot of minor bugfixes and enhancements, so we should get out 1.0.2 ASAP. Further enhancements should go into 1.0.3, scheduled for late June.
>>
>>Juergen
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

Re: [Springframework-developer] Preparing for 1.0.2

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

Doesn't j2ee.jar include the entire J2EE RI, rather than just the J2EE =
APIs? In any case, I prefer the individual jars, as they allow to pick =
individual API versions rather than a particular J2EE collective. They =
also allow application developers to pick just the API jars that they =
actually need to compile against.
=20
So if we need JCA for some odd reason, I vote for adding the individual =
jca.jar to our libs. However,=20
I don' t know of any JCA dependency in our code... Everything compiled =
nicely on my machine - without JCA.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Thomas Risberg
Gesendet: Sa 22.05.2004 22:26
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.2



I get an error in Eclipse - can't find javax.resource.Referencable.
That's part of JCA I think and it does not seem to be in any of our j2ee
libs. Why don't we replace servlet.jar, ejb.jar, jdbc2_0-stdext.jar,
jms.jar and jta.jar with the full j2ee.jar. That way we have all the
dependencies resolved. What version? I tried 1.3 and with it everything
compiles. The new 1.4 seems to have some new methods in some of the
interfaces and some of our MockObject implementations did not compile.

Thomas

j=FCrgen h=F6ller [werk3AT] wrote:

>Hi everybody,
>
>I've just finished my final preparations for our upcoming Spring =
release 1.0.2, scheduled for Sunday night. See the changelog for =
details; most issues have been discussed on the mailing lists or in =
JIRA. All remaining issues in JIRA have been addressed but do not incur =
Spring changes; I plan to close most of them at the time of the 1.0.2 =
release, resolved as "Won't fix".
>
>I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate =
2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons =
Attributes May 9th snapshot. (Will Commons Attributes ever get out of =
the Jakarta sandbox?? At least some sort of official beta release would =
be nice.) BTW, MockObjects is no longer in our libraries, neither in CVS =
nor in the release distribution, as we don't use it anymore.
>
>I plan to create the actual release Sunday night. So for all you =
weekend workhorses out there, there's still a chance to test and review =
the current CVS head :-) Please no further enhancements, though: As the =
changelog shows, we've already gathered a lot of minor bugfixes and =
enhancements, so we should get out 1.0.2 ASAP. Further enhancements =
should go into 1.0.3, scheduled for late June.
>
>Juergen
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle =
10g.
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>=20
>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.0.2

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

I'm just wondering what part of the code base has a dependency on JCA?

Dmitriy.


Thomas Risberg wrote:

> I get an error in Eclipse - can't find javax.resource.Referencable. 
> That's part of JCA I think and it does not seem to be in any of our 
> j2ee libs. Why don't we replace servlet.jar, ejb.jar, 
> jdbc2_0-stdext.jar, jms.jar and jta.jar with the full j2ee.jar. That 
> way we have all the dependencies resolved. What version? I tried 1.3 
> and with it everything compiles. The new 1.4 seems to have some new 
> methods in some of the interfaces and some of our MockObject 
> implementations did not compile.
>
> Thomas
>
> jürgen höller [werk3AT] wrote:
>
>> Hi everybody,
>>
>> I've just finished my final preparations for our upcoming Spring 
>> release 1.0.2, scheduled for Sunday night. See the changelog for 
>> details; most issues have been discussed on the mailing lists or in 
>> JIRA. All remaining issues in JIRA have been addressed but do not 
>> incur Spring changes; I plan to close most of them at the time of the 
>> 1.0.2 release, resolved as "Won't fix".
>>
>> I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate 
>> 2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons 
>> Attributes May 9th snapshot. (Will Commons Attributes ever get out of 
>> the Jakarta sandbox?? At least some sort of official beta release 
>> would be nice.) BTW, MockObjects is no longer in our libraries, 
>> neither in CVS nor in the release distribution, as we don't use it 
>> anymore.
>>
>> I plan to create the actual release Sunday night. So for all you 
>> weekend workhorses out there, there's still a chance to test and 
>> review the current CVS head :-) Please no further enhancements, 
>> though: As the changelog shows, we've already gathered a lot of minor 
>> bugfixes and enhancements, so we should get out 1.0.2 ASAP. Further 
>> enhancements should go into 1.0.3, scheduled for late June.
>>
>> Juergen
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>  
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Projects in JIRA

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

I've created two new project in JIRA for RCP and IDE:

* Rcp support: project key RCP, lead developer Keith Donald
* Eclipse plugin project: key IDE, lead developer Torsten Juergeleit

I've made Keith and Torsten jira-administrators, so they can go ahead 
and create project components for their respective projects as necessary.
Also I've made Juergen a lead developer for the core Spring project, so 
all the issues are assigned to him by default.

Regards,
Dmitriy.


jürgen höller [werk3AT] wrote:

>Furthermore, we could consider setting myself as lead developer in our JIRA. Currently, all newly reported issues are automatically assigned to Rod: What I typically do at first sight is reassign each issue to me, as I'm de facto the one who either cares for the issue or dispatches it accordingly. Of course, configuring JIRA in some other way to use myself as default assignee would also be fine.
> 
>Juergen
> 
>
>________________________________
>
>Von: jürgen höller [werk3AT]
>Gesendet: Sa 22.05.2004 20:19
>An: spr...@li...
>Betreff: Projects in JIRA
>
>
>We should create separate projects in our JIRA for "spring-ide" and "spring-rcp". People are currently reporting such issues for the main Spring project; obviously, version numbers don't match etc.
> 
>In a separate project definition, there would be an own set of versions to report against, and a clear separation of issues in the first place.
> 
>"spring-rcp" is currently a module of the Spring project in JIRA; "spring-ide" is not even a module yet. I suggest to turn both into separate project definitions.
> 
>Juergen
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] Preparing for 1.0.2

[Thomas R. <tho...@tr...>]

I get an error in Eclipse - can't find javax.resource.Referencable. 
That's part of JCA I think and it does not seem to be in any of our j2ee 
libs. Why don't we replace servlet.jar, ejb.jar, jdbc2_0-stdext.jar, 
jms.jar and jta.jar with the full j2ee.jar. That way we have all the 
dependencies resolved. What version? I tried 1.3 and with it everything 
compiles. The new 1.4 seems to have some new methods in some of the 
interfaces and some of our MockObject implementations did not compile.

Thomas

jürgen höller [werk3AT] wrote:

>Hi everybody,
> 
>I've just finished my final preparations for our upcoming Spring release 1.0.2, scheduled for Sunday night. See the changelog for details; most issues have been discussed on the mailing lists or in JIRA. All remaining issues in JIRA have been addressed but do not incur Spring changes; I plan to close most of them at the time of the 1.0.2 release, resolved as "Won't fix".
> 
>I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate 2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons Attributes May 9th snapshot. (Will Commons Attributes ever get out of the Jakarta sandbox?? At least some sort of official beta release would be nice.) BTW, MockObjects is no longer in our libraries, neither in CVS nor in the release distribution, as we don't use it anymore.
> 
>I plan to create the actual release Sunday night. So for all you weekend workhorses out there, there's still a chance to test and review the current CVS head :-) Please no further enhancements, though: As the changelog shows, we've already gathered a lot of minor bugfixes and enhancements, so we should get out 1.0.2 ASAP. Further enhancements should go into 1.0.3, scheduled for late June.
> 
>Juergen
> 
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id149&alloc_id66&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

[Springframework-developer] Re: Projects in JIRA

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

Furthermore, we could consider setting myself as lead developer in our =
JIRA. Currently, all newly reported issues are automatically assigned to =
Rod: What I typically do at first sight is reassign each issue to me, as =
I'm de facto the one who either cares for the issue or dispatches it =
accordingly. Of course, configuring JIRA in some other way to use myself =
as default assignee would also be fine.
=20
Juergen
=20

________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 22.05.2004 20:19
An: spr...@li...
Betreff: Projects in JIRA


We should create separate projects in our JIRA for "spring-ide" and =
"spring-rcp". People are currently reporting such issues for the main =
Spring project; obviously, version numbers don't match etc.
=20
In a separate project definition, there would be an own set of versions =
to report against, and a clear separation of issues in the first place.
=20
"spring-rcp" is currently a module of the Spring project in JIRA; =
"spring-ide" is not even a module yet. I suggest to turn both into =
separate project definitions.
=20
Juergen

[Springframework-developer] Projects in JIRA

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

We should create separate projects in our JIRA for "spring-ide" and =
"spring-rcp". People are currently reporting such issues for the main =
Spring project; obviously, version numbers don't match etc.
=20
In a separate project definition, there would be an own set of versions =
to report against, and a clear separation of issues in the first place.
=20
"spring-rcp" is currently a module of the Spring project in JIRA; =
"spring-ide" is not even a module yet. I suggest to turn both into =
separate project definitions.
=20
Juergen

Re: [Springframework-developer] Preparing for 1.0.2

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

Matt,
=20
We still haven't decided on how to proceed with the Commons Validator =
stuff; for the time being, it remains in the sandbox. If you like, =
please create an issue in our JIRA for it!
=20
As far as I see, it's just 8 classes, including a specific JSP custom =
tag; so I could imagine that we include it as part of the Spring =
distribution. I'm not sure if it should be part of Keith's emerging =
"spring-rules" subproject; that's rather gonna be a separate rules-based =
validation engine with its own plug into Spring's validation. And 8 =
integration classes aren't a convincing candidate for an own subproject =
either.
=20
You have used those Commons Validator integration classes pretty =
intensely, haven't you? Do you already consider them comprehensive =
enough for a release? Do you see any room for improvement there? Do you =
know of any existing alternative validation libraries that people could =
also want to have plugged into Spring? (To me, Commons Validator seems =
to be the only candidate for direct support in Spring at this point of =
time.)
=20
I wouldn't mind Spring 1.0.3 as target milestone for it, provided that =
we agree that Commons Validator support should be part of the Spring =
distribution. Interestingly enough, we already ship =
commons-validator.jar, because it is a runtime requirement of Struts - =
so we wouldn't even have to ship any further dependencies.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Sa 22.05.2004 17:27
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.2



It doesn't appear that the Commons Validator stuff will be in this
release.  Will that be in a future release - or is it dependent on the
declarative validation framework (that I believe Keith is still working
on)?

Matt

On May 22, 2004, at 8:10 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Hi everybody,
>
> I've just finished my final preparations for our upcoming Spring
> release 1.0.2, scheduled for Sunday night. See the changelog for
> details; most issues have been discussed on the mailing lists or in
> JIRA. All remaining issues in JIRA have been addressed but do not
> incur Spring changes; I plan to close most of them at the time of the
> 1.0.2 release, resolved as "Won't fix".
>
> I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate
> 2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons
> Attributes May 9th snapshot. (Will Commons Attributes ever get out of
> the Jakarta sandbox?? At least some sort of official beta release
> would be nice.) BTW, MockObjects is no longer in our libraries,
> neither in CVS nor in the release distribution, as we don't use it
> anymore.
>
> I plan to create the actual release Sunday night. So for all you
> weekend workhorses out there, there's still a chance to test and
> review the current CVS head :-) Please no further enhancements,
> though: As the changelog shows, we've already gathered a lot of minor
> bugfixes and enhancements, so we should get out 1.0.2 ASAP. Further
> enhancements should go into 1.0.3, scheduled for late June.
>
> Juergen
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id(tm)66&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] New technique for working with <spring:bind>

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

Furthermore, Velocimacros - and therefore form simplification macros for =
Velocity that we might provide out-of-the-box - are available even for =
Servlet 2.2 (JSP 1.1) containers. So for older containers, Velocity will =
become an even more compelling choice as view technology, once we =
provide such default form macros.
=20
http://jakarta.apache.org/velocity/user-guide.html#Velocimacros =
<http://jakarta.apache.org/velocity/user-guide.html#Velocimacros>=20
=20
FreeMarker actually offers a macro mechanism very similar to Velocity's. =
Therefore, we should be available to provide analogous form =
simplification macros for FreeMarker - again, leveraging its native =
macro mechanism. Actually, the syntax is so similar to Velocity that we =
might be able to use the same set of macro files...
=20
http://www.freemarker.org/docs/dgui_misc_userdefdir.html =
<http://www.freemarker.org/docs/dgui_misc_userdefdir.html>=20
=20
Any volunteers for those 3 form macro sets? :-) Maybe Seth for JSP 2.0? =
Darren for Velocity, maybe also for FreeMarker? I'll care for overall =
consistency. Target milestone could already be Spring 1.0.3 (end of =
June), but 1.1 RC1 (end of August) would be good enough too.
=20
BTW, thanks, everybody, for all your input!
=20
Juergen
=20

________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 22.05.2004 19:27
An: spr...@li...
Betreff: Re: [Springframework-developer] New technique for working with =
<spring:bind>


Regarding Velocity, there is actually a similar native technique: =
Velocimacros can achieve more or less the same as JSP 2.0 tag files, in =
a pretty similar style. IIRC, Darren is using Velocimacros exactly for =
rendering form elements, just like Seth uses JSP 2.0 tag files.
=20
I guess such simplifications for form building will always be specific =
to a view technology. What we could do is ship both default JSP 2.0 tag =
files *and* default Velocimacros for simplified form rendering, keeping =
them as analogous as possible (fetching dynamic values via bind tags =
respectively the RequestContext).
=20
In both cases, Java code would not issue HTML; rather, the HTML code is =
always kept in a template that allows for easy customization. I believe =
that having such analogous solutions for both JSP 2.0 and Velocity (and =
possibly FreeMarker) is quite promising.
=20
There's also value in leveraging the respective native macro mechanism =
of each view technology: This allows for natural integration without =
special bridges, also avoiding the need to learn yet another macro =
mechanism if you already know your view technology's native one.
=20
You do have a point that JSP 1.x does not have such a native macro =
mechanism. Of course, there's still the option of coding the form =
elements directly (just like our current samples do), so those users are =
by no means locked out. And as you say, it's a good reason for them to =
upgrade to JSP 2.0 :-)
=20
Whether or not to provide Java-coded form simplification tags for JSP =
1.2 is a question of tradeoff. For JSP 2.0, tag files are absolutely =
preferable, so Java-coded tags for JSP 1.2 would be a completely =
separate effort - even more extra effort if also attempting to provide a =
customization option for the HTML code.
=20
My personal point of view is that we should focus on providing good form =
simplification macros for JSP 2.0 and Velocity / FreeMarker, and keep =
recommending direct form elements with bind tags for JSP 1.2. Time is on =
our side in that respect, inevitably leading to broader adoption of JSP =
2.0.
=20
And of course, there's always the option of using Struts or WebWork on =
top of a Spring middle tier. Particularly for JSP 1.1, Struts is a =
compelling option, as its tags work there too. For JSP 1.2, both Struts =
and WebWork are viable choices for scenarios where form simplification =
macros are important.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Sa 22.05.2004 17:38
An: spr...@li...
Betreff: Re: [Springframework-developer] New technique for working with =
<spring:bind>



I agree that JSP 2.0 tag files for rendering form elements is a *very*
cool idea.  Unfortunately, there will probably be some flack from the
community because it won't work on most of the containers out there.=20
However, I think it's a good thing - let's drag those suckers into
using JSP 2.0 and help them simplify their lives. ;-) Hopefully more
containers will start producing J2EE 1.4-compatible servers.  To my
knowledge, only Tomcat, Resin and WebSphere support JSP 2.0.

The one nice thing about the WW tags is that they can actually be used
in both Velocity templates or in JSP pages.  I believe that's
accomplished with some Velocity magic that invokes JSP Tags.  It would
be nice if whatever Spring develops (to simplify JSP forms) can also be
used to simplify Velocity forms.

Matt

On May 22, 2004, at 5:48 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Seth,
>
> I do see what you intend setNestedPath for - I just feel that Matt has
> "misused" it in his example: In his 2-input-field form, setNestedPath
> complicates matters rather than simplifies it; this is definitely
> *not* "the Spring version that requires less typing" (as Matt has put
> it). Please read my initial post mainly as direct reaction to Matt's
> blog entry rather than as critique of setNestedPath per se.
>
> For a large number of input fields, setting a specific nested path in
> an outer tag does indeed simplify things. But even more important is
> that it allows for reuse of entire sub-forms, like Jon has pointed out
> with his address example; that was what I had in mind with reusing
> bind tag snippets. This usage is similar to setNestedPath on an Errors
> object (which is where you got the original idea from, I assume).
>
> Your "ideal looking page" is exactly what I envisage as optimal use of
> JSP 2.0 with Spring! With such concise input field syntax, specifying
> the nested path in an outer tag already makes sense for a small number
> of fields - agreed. It might be worth designing a "form:form" tag (as
> JSP 2.0 tag file) that sets the nested path (using setNestedPath
> underneath) but also renders a corresponding HTML form tag, analogous
> to Struts' "html:form".
>
> So moving forward, I consider adding a setNestedPath-style tag to
> Spring's standard tag library, possibly as "spring:nestedPath" (no
> "set" in the name, analogous to "spring:htmlEscape"). This does make
> sense both with and without JSP 2.0, so should be part of Spring's
> standard (Java-coded) tag library, I guess. Multiple
> "spring:nestedPath" tags could also be nested, building hierarchical
> nested paths.
>
> Have you considered donating your "form" tag library (JSP 2.0 tag
> files) to Spring? It's exactly what I had in mind with my suggestion
> in yesterday's blog comment. It would be a welcome option in standard
> Spring, and an excellent showcase for JSP 2.0 tag files: high-level
> HTML-issuing tags (coded as tag files) built on lower-level value
> access tags (classic Java-coded tags).
>
> Such a form tag library coded as JSP 2.0 tag files is much preferable
> to (Struts-style) classic Java-coded tags for each and every input
> field type, IMO, mainly because it's so easy to customize. There is
> still no HTML content in Java code -rather in JSP tag files. I believe
> that this is a very viable alternative to WebWork's form tags that
> issue HTML content from corresponding Velocity templates.
>
> Spring 1.0.2 will be released on Monday, so we should avoid further
> new functionality there. I plan to add "spring:nestedPath" for 1.0.3;
> it would be great to already have a basic "form" tag file library in
> that release too (or in 1.1 RC1)! A sample application that
> illustrates usage of those tag files is a necessity (of course, that
> sample will require JSP 2.0): maybe alternative JSP views for
> JPetStore's Spring web tier?
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von Seth Ladd
> Gesendet: Sa 22.05.2004 00:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Re: [Springframework-user]
> New technique for working with <spring:bind>
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks Juergen for pointing out this post.
>
>
> | Actually, Seth's version does *not* require less typing: It just
> avoids repeating the command name. Without Seth's setNestedPath tag,
> you'll get the 3 lines per field, saying "command.firstName"
> respectively "command.lastName". I actually prefer the latter; I
> personally don't think that such a setNestedPath tag adds value -
> except
> for very repetitive forms where you reuse the same bind tag snippet =
for
> various command names.
>
> That's exactly why I would want it and use it.  I don't want to repeat
> anything.  The setNestedPath tag follows very closely the bind tag.
> That is, just helps with setting scope of a bean that bind is using.
> It's entirely optional, too.  The bind tag works/should work just fine
> without it.  I've found it very useful in developing our JSPs that use
> many fields, where many of the fields are withing nested objects.
>
> I still believe it saves typing for anything more than 2 fields.  =
Also,
> it saves a chance for error, as I'm not repeating the command name =
over
> and over.
>
> Having said that...
>
> |
> | If someone wants to reuse bind tags with specific HTML portions,
> simply turn them into parameterizable snippets: for example, with JSP
> 2.0's tag files. It should be straightforward to define Struts-style
> "html:xxx" custom tags this way, using the bind tag (or
> RequestContext/Errors scriptlets) underneath. I think this is a viable
> alternative to WebWork's way of custom tags rendering Velocity
> templates, being equally powerful.
>
> That's exactly what I, and I suspect many, people are doing right now.
> I've wrapped the bind tag and the logic to render the HTML (for
> instance, select and option tags) inside a tag file.  Using the
> struts-esque tag files + setNestedPath, I'm pretty close to very
> minimal
> JSP typing.
>
> I see setNestedPath as an optional, but extremely helpful tag when
> writing anything but the most simple JSP page.  I then see a separate
> set of convinience tags/tag files that render HTML markup as a really
> nice value add that everyone will end up writing anyway.
>
> See the original wiki page that started this.  There is a comment =
there
> that gives examples of these tag files.
>
> My ideal looking page (and what I'm using now):
>
> <springx:setNestedPath path=3D"command">
>
> First Name: <form:text name=3D"firstName"/>
> Last Name: <form:text name=3D"lastName" />
>
> Address:
> <springx:setNestedPath path=3D"address">
> Street1: <form:text name=3D"street1"/>
> Street2: <form:text name=3D"street2"/>
> ...
> </springx:setNestedPath>
>
> <input type=3D"submit"/>
> </springx:setNestedPath>
>
> Hope that helps.
>
> Thanks,
> Seth
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFArnxpKZsFSwtW+wIRAvUmAJ92o8EtbvaoyqGBd+MJa7apQRisXgCeO72t
> PHxE0WKTDhfnnfi20RfGThA=3D
> =3DoMwA
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id(tm)66&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] New technique for working with <spring:bind>

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

Regarding Velocity, there is actually a similar native technique: =
Velocimacros can achieve more or less the same as JSP 2.0 tag files, in =
a pretty similar style. IIRC, Darren is using Velocimacros exactly for =
rendering form elements, just like Seth uses JSP 2.0 tag files.
=20
I guess such simplifications for form building will always be specific =
to a view technology. What we could do is ship both default JSP 2.0 tag =
files *and* default Velocimacros for simplified form rendering, keeping =
them as analogous as possible (fetching dynamic values via bind tags =
respectively the RequestContext).
=20
In both cases, Java code would not issue HTML; rather, the HTML code is =
always kept in a template that allows for easy customization. I believe =
that having such analogous solutions for both JSP 2.0 and Velocity (and =
possibly FreeMarker) is quite promising.
=20
There's also value in leveraging the respective native macro mechanism =
of each view technology: This allows for natural integration without =
special bridges, also avoiding the need to learn yet another macro =
mechanism if you already know your view technology's native one.
=20
You do have a point that JSP 1.x does not have such a native macro =
mechanism. Of course, there's still the option of coding the form =
elements directly (just like our current samples do), so those users are =
by no means locked out. And as you say, it's a good reason for them to =
upgrade to JSP 2.0 :-)
=20
Whether or not to provide Java-coded form simplification tags for JSP =
1.2 is a question of tradeoff. For JSP 2.0, tag files are absolutely =
preferable, so Java-coded tags for JSP 1.2 would be a completely =
separate effort - even more extra effort if also attempting to provide a =
customization option for the HTML code.
=20
My personal point of view is that we should focus on providing good form =
simplification macros for JSP 2.0 and Velocity / FreeMarker, and keep =
recommending direct form elements with bind tags for JSP 1.2. Time is on =
our side in that respect, inevitably leading to broader adoption of JSP =
2.0.
=20
And of course, there's always the option of using Struts or WebWork on =
top of a Spring middle tier. Particularly for JSP 1.1, Struts is a =
compelling option, as its tags work there too. For JSP 1.2, both Struts =
and WebWork are viable choices for scenarios where form simplification =
macros are important.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Sa 22.05.2004 17:38
An: spr...@li...
Betreff: Re: [Springframework-developer] New technique for working with =
<spring:bind>



I agree that JSP 2.0 tag files for rendering form elements is a *very*
cool idea.  Unfortunately, there will probably be some flack from the
community because it won't work on most of the containers out there.=20
However, I think it's a good thing - let's drag those suckers into
using JSP 2.0 and help them simplify their lives. ;-) Hopefully more
containers will start producing J2EE 1.4-compatible servers.  To my
knowledge, only Tomcat, Resin and WebSphere support JSP 2.0.

The one nice thing about the WW tags is that they can actually be used
in both Velocity templates or in JSP pages.  I believe that's
accomplished with some Velocity magic that invokes JSP Tags.  It would
be nice if whatever Spring develops (to simplify JSP forms) can also be
used to simplify Velocity forms.

Matt

On May 22, 2004, at 5:48 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Seth,
>
> I do see what you intend setNestedPath for - I just feel that Matt has
> "misused" it in his example: In his 2-input-field form, setNestedPath
> complicates matters rather than simplifies it; this is definitely
> *not* "the Spring version that requires less typing" (as Matt has put
> it). Please read my initial post mainly as direct reaction to Matt's
> blog entry rather than as critique of setNestedPath per se.
>
> For a large number of input fields, setting a specific nested path in
> an outer tag does indeed simplify things. But even more important is
> that it allows for reuse of entire sub-forms, like Jon has pointed out
> with his address example; that was what I had in mind with reusing
> bind tag snippets. This usage is similar to setNestedPath on an Errors
> object (which is where you got the original idea from, I assume).
>
> Your "ideal looking page" is exactly what I envisage as optimal use of
> JSP 2.0 with Spring! With such concise input field syntax, specifying
> the nested path in an outer tag already makes sense for a small number
> of fields - agreed. It might be worth designing a "form:form" tag (as
> JSP 2.0 tag file) that sets the nested path (using setNestedPath
> underneath) but also renders a corresponding HTML form tag, analogous
> to Struts' "html:form".
>
> So moving forward, I consider adding a setNestedPath-style tag to
> Spring's standard tag library, possibly as "spring:nestedPath" (no
> "set" in the name, analogous to "spring:htmlEscape"). This does make
> sense both with and without JSP 2.0, so should be part of Spring's
> standard (Java-coded) tag library, I guess. Multiple
> "spring:nestedPath" tags could also be nested, building hierarchical
> nested paths.
>
> Have you considered donating your "form" tag library (JSP 2.0 tag
> files) to Spring? It's exactly what I had in mind with my suggestion
> in yesterday's blog comment. It would be a welcome option in standard
> Spring, and an excellent showcase for JSP 2.0 tag files: high-level
> HTML-issuing tags (coded as tag files) built on lower-level value
> access tags (classic Java-coded tags).
>
> Such a form tag library coded as JSP 2.0 tag files is much preferable
> to (Struts-style) classic Java-coded tags for each and every input
> field type, IMO, mainly because it's so easy to customize. There is
> still no HTML content in Java code -rather in JSP tag files. I believe
> that this is a very viable alternative to WebWork's form tags that
> issue HTML content from corresponding Velocity templates.
>
> Spring 1.0.2 will be released on Monday, so we should avoid further
> new functionality there. I plan to add "spring:nestedPath" for 1.0.3;
> it would be great to already have a basic "form" tag file library in
> that release too (or in 1.1 RC1)! A sample application that
> illustrates usage of those tag files is a necessity (of course, that
> sample will require JSP 2.0): maybe alternative JSP views for
> JPetStore's Spring web tier?
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von Seth Ladd
> Gesendet: Sa 22.05.2004 00:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Re: [Springframework-user]
> New technique for working with <spring:bind>
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks Juergen for pointing out this post.
>
>
> | Actually, Seth's version does *not* require less typing: It just
> avoids repeating the command name. Without Seth's setNestedPath tag,
> you'll get the 3 lines per field, saying "command.firstName"
> respectively "command.lastName". I actually prefer the latter; I
> personally don't think that such a setNestedPath tag adds value -
> except
> for very repetitive forms where you reuse the same bind tag snippet =
for
> various command names.
>
> That's exactly why I would want it and use it.  I don't want to repeat
> anything.  The setNestedPath tag follows very closely the bind tag.
> That is, just helps with setting scope of a bean that bind is using.
> It's entirely optional, too.  The bind tag works/should work just fine
> without it.  I've found it very useful in developing our JSPs that use
> many fields, where many of the fields are withing nested objects.
>
> I still believe it saves typing for anything more than 2 fields.  =
Also,
> it saves a chance for error, as I'm not repeating the command name =
over
> and over.
>
> Having said that...
>
> |
> | If someone wants to reuse bind tags with specific HTML portions,
> simply turn them into parameterizable snippets: for example, with JSP
> 2.0's tag files. It should be straightforward to define Struts-style
> "html:xxx" custom tags this way, using the bind tag (or
> RequestContext/Errors scriptlets) underneath. I think this is a viable
> alternative to WebWork's way of custom tags rendering Velocity
> templates, being equally powerful.
>
> That's exactly what I, and I suspect many, people are doing right now.
> I've wrapped the bind tag and the logic to render the HTML (for
> instance, select and option tags) inside a tag file.  Using the
> struts-esque tag files + setNestedPath, I'm pretty close to very
> minimal
> JSP typing.
>
> I see setNestedPath as an optional, but extremely helpful tag when
> writing anything but the most simple JSP page.  I then see a separate
> set of convinience tags/tag files that render HTML markup as a really
> nice value add that everyone will end up writing anyway.
>
> See the original wiki page that started this.  There is a comment =
there
> that gives examples of these tag files.
>
> My ideal looking page (and what I'm using now):
>
> <springx:setNestedPath path=3D"command">
>
> First Name: <form:text name=3D"firstName"/>
> Last Name: <form:text name=3D"lastName" />
>
> Address:
> <springx:setNestedPath path=3D"address">
> Street1: <form:text name=3D"street1"/>
> Street2: <form:text name=3D"street2"/>
> ...
> </springx:setNestedPath>
>
> <input type=3D"submit"/>
> </springx:setNestedPath>
>
> Hope that helps.
>
> Thanks,
> Seth
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFArnxpKZsFSwtW+wIRAvUmAJ92o8EtbvaoyqGBd+MJa7apQRisXgCeO72t
> PHxE0WKTDhfnnfi20RfGThA=3D
> =3DoMwA
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id(tm)66&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] New technique for working with <spring:bind>

[Matt R. <li...@ra...>]

I agree that JSP 2.0 tag files for rendering form elements is a *very*=20=

cool idea.  Unfortunately, there will probably be some flack from the=20
community because it won't work on most of the containers out there. =20
However, I think it's a good thing - let's drag those suckers into=20
using JSP 2.0 and help them simplify their lives. ;-) Hopefully more=20
containers will start producing J2EE 1.4-compatible servers.  To my=20
knowledge, only Tomcat, Resin and WebSphere support JSP 2.0.

The one nice thing about the WW tags is that they can actually be used=20=

in both Velocity templates or in JSP pages.  I believe that's=20
accomplished with some Velocity magic that invokes JSP Tags.  It would=20=

be nice if whatever Spring develops (to simplify JSP forms) can also be=20=

used to simplify Velocity forms.

Matt

On May 22, 2004, at 5:48 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Seth,
>
> I do see what you intend setNestedPath for - I just feel that Matt has=20=

> "misused" it in his example: In his 2-input-field form, setNestedPath=20=

> complicates matters rather than simplifies it; this is definitely=20
> *not* "the Spring version that requires less typing" (as Matt has put=20=

> it). Please read my initial post mainly as direct reaction to Matt's=20=

> blog entry rather than as critique of setNestedPath per se.
>
> For a large number of input fields, setting a specific nested path in=20=

> an outer tag does indeed simplify things. But even more important is=20=

> that it allows for reuse of entire sub-forms, like Jon has pointed out=20=

> with his address example; that was what I had in mind with reusing=20
> bind tag snippets. This usage is similar to setNestedPath on an Errors=20=

> object (which is where you got the original idea from, I assume).
>
> Your "ideal looking page" is exactly what I envisage as optimal use of=20=

> JSP 2.0 with Spring! With such concise input field syntax, specifying=20=

> the nested path in an outer tag already makes sense for a small number=20=

> of fields - agreed. It might be worth designing a "form:form" tag (as=20=

> JSP 2.0 tag file) that sets the nested path (using setNestedPath=20
> underneath) but also renders a corresponding HTML form tag, analogous=20=

> to Struts' "html:form".
>
> So moving forward, I consider adding a setNestedPath-style tag to=20
> Spring's standard tag library, possibly as "spring:nestedPath" (no=20
> "set" in the name, analogous to "spring:htmlEscape"). This does make=20=

> sense both with and without JSP 2.0, so should be part of Spring's=20
> standard (Java-coded) tag library, I guess. Multiple=20
> "spring:nestedPath" tags could also be nested, building hierarchical=20=

> nested paths.
>
> Have you considered donating your "form" tag library (JSP 2.0 tag=20
> files) to Spring? It's exactly what I had in mind with my suggestion=20=

> in yesterday's blog comment. It would be a welcome option in standard=20=

> Spring, and an excellent showcase for JSP 2.0 tag files: high-level=20
> HTML-issuing tags (coded as tag files) built on lower-level value=20
> access tags (classic Java-coded tags).
>
> Such a form tag library coded as JSP 2.0 tag files is much preferable=20=

> to (Struts-style) classic Java-coded tags for each and every input=20
> field type, IMO, mainly because it's so easy to customize. There is=20
> still no HTML content in Java code -rather in JSP tag files. I believe=20=

> that this is a very viable alternative to WebWork's form tags that=20
> issue HTML content from corresponding Velocity templates.
>
> Spring 1.0.2 will be released on Monday, so we should avoid further=20
> new functionality there. I plan to add "spring:nestedPath" for 1.0.3;=20=

> it would be great to already have a basic "form" tag file library in=20=

> that release too (or in 1.1 RC1)! A sample application that=20
> illustrates usage of those tag files is a necessity (of course, that=20=

> sample will require JSP 2.0): maybe alternative JSP views for=20
> JPetStore's Spring web tier?
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag=20=

> von Seth Ladd
> Gesendet: Sa 22.05.2004 00:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Re: [Springframework-user]=20
> New technique for working with <spring:bind>
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks Juergen for pointing out this post.
>
>
> | Actually, Seth's version does *not* require less typing: It just
> avoids repeating the command name. Without Seth's setNestedPath tag,
> you'll get the 3 lines per field, saying "command.firstName"
> respectively "command.lastName". I actually prefer the latter; I
> personally don't think that such a setNestedPath tag adds value -=20
> except
> for very repetitive forms where you reuse the same bind tag snippet =
for
> various command names.
>
> That's exactly why I would want it and use it.  I don't want to repeat
> anything.  The setNestedPath tag follows very closely the bind tag.
> That is, just helps with setting scope of a bean that bind is using.
> It's entirely optional, too.  The bind tag works/should work just fine
> without it.  I've found it very useful in developing our JSPs that use
> many fields, where many of the fields are withing nested objects.
>
> I still believe it saves typing for anything more than 2 fields.  =
Also,
> it saves a chance for error, as I'm not repeating the command name =
over
> and over.
>
> Having said that...
>
> |
> | If someone wants to reuse bind tags with specific HTML portions,
> simply turn them into parameterizable snippets: for example, with JSP
> 2.0's tag files. It should be straightforward to define Struts-style
> "html:xxx" custom tags this way, using the bind tag (or
> RequestContext/Errors scriptlets) underneath. I think this is a viable
> alternative to WebWork's way of custom tags rendering Velocity
> templates, being equally powerful.
>
> That's exactly what I, and I suspect many, people are doing right now.
> I've wrapped the bind tag and the logic to render the HTML (for
> instance, select and option tags) inside a tag file.  Using the
> struts-esque tag files + setNestedPath, I'm pretty close to very=20
> minimal
> JSP typing.
>
> I see setNestedPath as an optional, but extremely helpful tag when
> writing anything but the most simple JSP page.  I then see a separate
> set of convinience tags/tag files that render HTML markup as a really
> nice value add that everyone will end up writing anyway.
>
> See the original wiki page that started this.  There is a comment =
there
> that gives examples of these tag files.
>
> My ideal looking page (and what I'm using now):
>
> <springx:setNestedPath path=3D"command">
>
> First Name: <form:text name=3D"firstName"/>
> Last Name: <form:text name=3D"lastName" />
>
> Address:
> <springx:setNestedPath path=3D"address">
> Street1: <form:text name=3D"street1"/>
> Street2: <form:text name=3D"street2"/>
> ...
> </springx:setNestedPath>
>
> <input type=3D"submit"/>
> </springx:setNestedPath>
>
> Hope that helps.
>
> Thanks,
> Seth
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFArnxpKZsFSwtW+wIRAvUmAJ92o8EtbvaoyqGBd+MJa7apQRisXgCeO72t
> PHxE0WKTDhfnnfi20RfGThA=3D
> =3DoMwA
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle=20
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle=20
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=9966&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Preparing for 1.0.2

[Matt R. <li...@ra...>]

It doesn't appear that the Commons Validator stuff will be in this=20
release.  Will that be in a future release - or is it dependent on the=20=

declarative validation framework (that I believe Keith is still working=20=

on)?

Matt

On May 22, 2004, at 8:10 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Hi everybody,
>
> I've just finished my final preparations for our upcoming Spring=20
> release 1.0.2, scheduled for Sunday night. See the changelog for=20
> details; most issues have been discussed on the mailing lists or in=20
> JIRA. All remaining issues in JIRA have been addressed but do not=20
> incur Spring changes; I plan to close most of them at the time of the=20=

> 1.0.2 release, resolved as "Won't fix".
>
> I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate=20
> 2.1.3, iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons=20
> Attributes May 9th snapshot. (Will Commons Attributes ever get out of=20=

> the Jakarta sandbox?? At least some sort of official beta release=20
> would be nice.) BTW, MockObjects is no longer in our libraries,=20
> neither in CVS nor in the release distribution, as we don't use it=20
> anymore.
>
> I plan to create the actual release Sunday night. So for all you=20
> weekend workhorses out there, there's still a chance to test and=20
> review the current CVS head :-) Please no further enhancements,=20
> though: As the changelog shows, we've already gathered a lot of minor=20=

> bugfixes and enhancements, so we should get out 1.0.2 ASAP. Further=20
> enhancements should go into 1.0.3, scheduled for late June.
>
> Juergen
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle=20
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=9966&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] "Import" feature

[Kirill M. <ki...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

~  I've implemented a small feature for bean definitions file - import.
~  The syntax the same as in Ant: <import file="relative/file.xml"/>

~  Yes, I know that the same effect can be obtained via entity
~  expansion, but I think it is inconvinient.

~  I hope you'll found it useful:
~  http://opensource.atlassian.com/projects/spring/browse/SPR-137

~  With kind regards,
~  KIR

- --
Kirill Maximov (aka KIR) | http://www.maxkir.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAr2q1E0YZ3264U5QRAloyAJ9265sVt/XbxTALVtWMRyZJgqqJBgCcD7kA
uFdCka/wJZ3gciBevzpjrUc=
=R4HS
-----END PGP SIGNATURE-----

[Springframework-developer] Preparing for 1.0.2

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

Hi everybody,
=20
I've just finished my final preparations for our upcoming Spring release =
1.0.2, scheduled for Sunday night. See the changelog for details; most =
issues have been discussed on the mailing lists or in JIRA. All =
remaining issues in JIRA have been addressed but do not incur Spring =
changes; I plan to close most of them at the time of the 1.0.2 release, =
resolved as "Won't fix".
=20
I've also updated our dependencies: FreeMarker 2.3 RC4, Hibernate 2.1.3, =
iBATIS SQL Maps 2.0 RC4, Velocity Tools 1.1 final, Commons Attributes =
May 9th snapshot. (Will Commons Attributes ever get out of the Jakarta =
sandbox?? At least some sort of official beta release would be nice.) =
BTW, MockObjects is no longer in our libraries, neither in CVS nor in =
the release distribution, as we don't use it anymore.
=20
I plan to create the actual release Sunday night. So for all you weekend =
workhorses out there, there's still a chance to test and review the =
current CVS head :-) Please no further enhancements, though: As the =
changelog shows, we've already gathered a lot of minor bugfixes and =
enhancements, so we should get out 1.0.2 ASAP. Further enhancements =
should go into 1.0.3, scheduled for late June.
=20
Juergen
=20

Re: [Springframework-developer] Cleanup of context resources on webapp reload

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

So basically, all static caches cause resource leaks when restarting a =
Tomcat web app? I wonder why this happens... The class loader should =
completely dissolve all classes that it has loaded in its lifetime, =
including static caches. Or have I misunderstood something here? Anyone =
having in-detail experience with handling such a scenario?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Dmitriy Kopylenko
Gesendet: Di 04.05.2004 18:02
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on =
webapp reload



Well,

for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which =
caches SQLErrorCodes internally in the Map with strong references. =
Again, I don't know if trying
to use WeakHashMap there would do the trick...

Dmitriy

Tim Kettering wrote:

>
> I looked at it some more this morning, and basically what I did was=20
> start up tomcat w/ the webapp in the profiler, then after it was done=20
> starting up I used tomcat's manager to stop the context.  This should=20
> destroy all resources related to the context.   Here is a list of=20
> spring related stuff that still were in memory after the context was=20
> closed.  Other stuff was cleaned up just fine.
>
> org.springframework.beans.CachedIntrospectionResults
> org.springframework.jdbc.support.SQLCodes
> org.springframework.core.Constants
> org.springframework.aop.framework.AdvisedSupport$1
> org.springframework.aop.framework.adapter.BeforeAdviceAdapter
> org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
> org.springframework.jdbc.support.SQLErrorCodesFactory
> =
org.springframework.transaction.support.TransactionSynchronizationManage
> r$1
> org.springframework.transaction.interceptor.RollbackRuleAttribute
> org.springframework.aop.framework.adapter.ThrosAdviceAdapter
> org.springframework.aop.Pointcut$1
> org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>
> On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>
>> I'm just wondering, would the use of WeakHashMap in=20
>> CachedIntrospectionResults help?
>>
>> Dmitriy.
>>
>> Tim Kettering wrote:
>>
>>> I posted this to the users list last week and did not receive any=20
>>> reply  on it, so I'm posting it again here on the developer list, in =

>>> hopes i  could get an reply from someone here.   I'm trying to=20
>>> determine if its  something I should be doing myself, or if hte=20
>>> spring context should be  cleaning up those resources by itself on=20
>>> the .close() call.  Further  profiling shows that there are
>>> duplicate  instances of SQLError and  hibernate proxy classes =
hanging
>>> around  afterwards too.  Other objects  do get cleaned up properly.
>>> --------
>>> Hi everyone,
>>> We're (meaning me) looking into some resource leaks that are
>>> occuring   when our webapp context gets reloaded.  I found that
>>> context.close()   needs to be called on the destroy() method of
>>> plugin we're using,  and  it works for a good majority of the =
objects
>>> we were seeing  leaked, but  there are some objects that I'm unable
>>> to make go away.  Object in  question is the:
>>> org.springframework.beans.CachedIntrospectionResults
>>> Whenever I reload the context - the profiler I'm using shows that I  =

>>> have essentially a duplicate group of those objects (same instance =20
>>> count) as the original, and successive reloads will continue to =20
>>> duplicate this.
>>> The profiler also shows the final reference to those objects like  =
this:
>>> 100% - 1008 bytes - 63 alloc. =20
>>> =
org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>> it >
>>> So basically I guess what I'm asking is for ideas or suggestions on=20
>>> how  I could get those to clean up.  This bean doesnt show up in the =

>>> Spring  javadocs.  And looking in CVS says its a package level bean, =

>>> not for  application use, so I'm thinking that closing the context=20
>>> should (in  theory) clean this up?   Thanks in advance.
>>> -tim
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: Oracle 10g
>>> Get certified on the hottest thing ever to hit the market... Oracle=20
>>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. =

>>> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle=20
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.=20
>> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: [Springframework-developer] New technique for working with <spring:bind>

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

Seth,
=20
I do see what you intend setNestedPath for - I just feel that Matt has =
"misused" it in his example: In his 2-input-field form, setNestedPath =
complicates matters rather than simplifies it; this is definitely *not* =
"the Spring version that requires less typing" (as Matt has put it). =
Please read my initial post mainly as direct reaction to Matt's blog =
entry rather than as critique of setNestedPath per se.
=20
For a large number of input fields, setting a specific nested path in an =
outer tag does indeed simplify things. But even more important is that =
it allows for reuse of entire sub-forms, like Jon has pointed out with =
his address example; that was what I had in mind with reusing bind tag =
snippets. This usage is similar to setNestedPath on an Errors object =
(which is where you got the original idea from, I assume).
=20
Your "ideal looking page" is exactly what I envisage as optimal use of =
JSP 2.0 with Spring! With such concise input field syntax, specifying =
the nested path in an outer tag already makes sense for a small number =
of fields - agreed. It might be worth designing a "form:form" tag (as =
JSP 2.0 tag file) that sets the nested path (using setNestedPath =
underneath) but also renders a corresponding HTML form tag, analogous to =
Struts' "html:form".
=20
So moving forward, I consider adding a setNestedPath-style tag to =
Spring's standard tag library, possibly as "spring:nestedPath" (no "set" =
in the name, analogous to "spring:htmlEscape"). This does make sense =
both with and without JSP 2.0, so should be part of Spring's standard =
(Java-coded) tag library, I guess. Multiple "spring:nestedPath" tags =
could also be nested, building hierarchical nested paths.
=20
Have you considered donating your "form" tag library (JSP 2.0 tag files) =
to Spring? It's exactly what I had in mind with my suggestion in =
yesterday's blog comment. It would be a welcome option in standard =
Spring, and an excellent showcase for JSP 2.0 tag files: high-level =
HTML-issuing tags (coded as tag files) built on lower-level value access =
tags (classic Java-coded tags).
=20
Such a form tag library coded as JSP 2.0 tag files is much preferable to =
(Struts-style) classic Java-coded tags for each and every input field =
type, IMO, mainly because it's so easy to customize. There is still no =
HTML content in Java code -rather in JSP tag files. I believe that this =
is a very viable alternative to WebWork's form tags that issue HTML =
content from corresponding Velocity templates.
=20
Spring 1.0.2 will be released on Monday, so we should avoid further new =
functionality there. I plan to add "spring:nestedPath" for 1.0.3; it =
would be great to already have a basic "form" tag file library in that =
release too (or in 1.1 RC1)! A sample application that illustrates usage =
of those tag files is a necessity (of course, that sample will require =
JSP 2.0): maybe alternative JSP views for JPetStore's Spring web tier?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Seth Ladd
Gesendet: Sa 22.05.2004 00:02
An: spr...@li...
Betreff: Re: [Springframework-developer] Re: [Springframework-user] New =
technique for working with <spring:bind>



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks Juergen for pointing out this post.


| Actually, Seth's version does *not* require less typing: It just
avoids repeating the command name. Without Seth's setNestedPath tag,
you'll get the 3 lines per field, saying "command.firstName"
respectively "command.lastName". I actually prefer the latter; I
personally don't think that such a setNestedPath tag adds value - except
for very repetitive forms where you reuse the same bind tag snippet for
various command names.

That's exactly why I would want it and use it.  I don't want to repeat
anything.  The setNestedPath tag follows very closely the bind tag.
That is, just helps with setting scope of a bean that bind is using.
It's entirely optional, too.  The bind tag works/should work just fine
without it.  I've found it very useful in developing our JSPs that use
many fields, where many of the fields are withing nested objects.

I still believe it saves typing for anything more than 2 fields.  Also,
it saves a chance for error, as I'm not repeating the command name over
and over.

Having said that...

|
| If someone wants to reuse bind tags with specific HTML portions,
simply turn them into parameterizable snippets: for example, with JSP
2.0's tag files. It should be straightforward to define Struts-style
"html:xxx" custom tags this way, using the bind tag (or
RequestContext/Errors scriptlets) underneath. I think this is a viable
alternative to WebWork's way of custom tags rendering Velocity
templates, being equally powerful.

That's exactly what I, and I suspect many, people are doing right now.
I've wrapped the bind tag and the logic to render the HTML (for
instance, select and option tags) inside a tag file.  Using the
struts-esque tag files + setNestedPath, I'm pretty close to very minimal
JSP typing.

I see setNestedPath as an optional, but extremely helpful tag when
writing anything but the most simple JSP page.  I then see a separate
set of convinience tags/tag files that render HTML markup as a really
nice value add that everyone will end up writing anyway.

See the original wiki page that started this.  There is a comment there
that gives examples of these tag files.

My ideal looking page (and what I'm using now):

<springx:setNestedPath path=3D"command">

First Name: <form:text name=3D"firstName"/>
Last Name: <form:text name=3D"lastName" />

Address:
<springx:setNestedPath path=3D"address">
Street1: <form:text name=3D"street1"/>
Street2: <form:text name=3D"street2"/>
...
</springx:setNestedPath>

<input type=3D"submit"/>
</springx:setNestedPath>

Hope that helps.

Thanks,
Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFArnxpKZsFSwtW+wIRAvUmAJ92o8EtbvaoyqGBd+MJa7apQRisXgCeO72t
PHxE0WKTDhfnnfi20RfGThA=3D
=3DoMwA
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: [Springframework-user] New technique for working with <spring:bind>

[Seth L. <se...@eh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks Juergen for pointing out this post.


| Actually, Seth's version does *not* require less typing: It just
avoids repeating the command name. Without Seth's setNestedPath tag,
you'll get the 3 lines per field, saying "command.firstName"
respectively "command.lastName". I actually prefer the latter; I
personally don't think that such a setNestedPath tag adds value - except
for very repetitive forms where you reuse the same bind tag snippet for
various command names.

That's exactly why I would want it and use it.  I don't want to repeat
anything.  The setNestedPath tag follows very closely the bind tag.
That is, just helps with setting scope of a bean that bind is using.
It's entirely optional, too.  The bind tag works/should work just fine
without it.  I've found it very useful in developing our JSPs that use
many fields, where many of the fields are withing nested objects.

I still believe it saves typing for anything more than 2 fields.  Also,
it saves a chance for error, as I'm not repeating the command name over
and over.

Having said that...

|
| If someone wants to reuse bind tags with specific HTML portions,
simply turn them into parameterizable snippets: for example, with JSP
2.0's tag files. It should be straightforward to define Struts-style
"html:xxx" custom tags this way, using the bind tag (or
RequestContext/Errors scriptlets) underneath. I think this is a viable
alternative to WebWork's way of custom tags rendering Velocity
templates, being equally powerful.

That's exactly what I, and I suspect many, people are doing right now.
I've wrapped the bind tag and the logic to render the HTML (for
instance, select and option tags) inside a tag file.  Using the
struts-esque tag files + setNestedPath, I'm pretty close to very minimal
JSP typing.

I see setNestedPath as an optional, but extremely helpful tag when
writing anything but the most simple JSP page.  I then see a separate
set of convinience tags/tag files that render HTML markup as a really
nice value add that everyone will end up writing anyway.

See the original wiki page that started this.  There is a comment there
that gives examples of these tag files.

My ideal looking page (and what I'm using now):

<springx:setNestedPath path="command">

First Name: <form:text name="firstName"/>
Last Name: <form:text name="lastName" />

Address:
<springx:setNestedPath path="address">
Street1: <form:text name="street1"/>
Street2: <form:text name="street2"/>
...
</springx:setNestedPath>

<input type="submit"/>
</springx:setNestedPath>

Hope that helps.

Thanks,
Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFArnxpKZsFSwtW+wIRAvUmAJ92o8EtbvaoyqGBd+MJa7apQRisXgCeO72t
PHxE0WKTDhfnnfi20RfGThA=
=oMwA
-----END PGP SIGNATURE-----