Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Colin S. <col...@ex...> - 2003-11-25 21:09:57
|
The issue is that Hibernate 2.1 is still in beta. So while it's hopefully ok for them to go to cglib 2 in their beta, the same thing does not necessarilly apply to us in our 1.0 RC and final releases. That is, I don't personally know what state cglib 2 is right now. We have to look at it ourselves. Even if we do go to cglib2, I think that may kill our ability to work with Hibernate 2.0, if cglib2 is not totally upwards compatible with cglib1. This is important to figure out... I'm actually unclear on why cglib embeds ASM themselves. It's a little bit annoying, as I use AMS outside of cglib, and that fact that it's in the cglib jar means I am tied to that version unless I want to do some surgery. jürgen höller [werk3AT] wrote: >Looking forward, I'm keen on getting out RC1 in December, right before Christmas if necessary - the goal as I see it is "this year". Our main concern will be documentation, I guess, as everything else should just be about bug-fixing and refining. If anyone wants to add a major new feature, feel free to go ahead but please tell the group and hurry up ;-) > >One point to get right for RC1 is correct packaging of third-party libraries. Like Hibernate, we should include the licenses of all packages that we ship. And we should update to the current versions of all libs. In particular, we need to pay attention to Hibernate 2.1: IIRC, they switched to CGLIB2 in the 2.1 tree, so we should check if our AOP framework can work with that too. After all, we have numerous users combining Hibernate and Spring's declarative transaction management. > >Agreement? Wishes? Complaints? > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von jürgen höller [werk3AT] >Gesendet: Di 25.11.2003 12:47 >An: spr...@li...; spr...@li... >Betreff: [Springframework-developer] Spring Framework 1.0 M3 released > > > >Hello everybody, > >I'm pleased to announce the release of Spring Framework 1.0 M3. This is the fifth public release towards 1.0 final. As you can see in the changelog, there have been lots of changes in this iteration. The next release will be 1.0 RC1; we do not plan any further milestone releases. > >M3 introduces significant new features and enhancements, among them: >- Type 3 IoC support in the bean factory (constructor resolution) >- bean factory SPI interfaces (package bean.factory.config) >- redesigned AOP API (more flexible pointcut handling etc) >- reworked and optimized transaction manager implementations >- fine-grained JDBC exception handling in the Hibernate support >- reworked JDO support with a new JdoDialect strategy >- reworked exception handling in the web framework >- working Tiles example application included > >Some of the changes will need migration of existing code, most notably: >- Controllers are now allowed to throw Exception (affecting BaseCommandController and AbstractFormController) >- some of BeanCommandController's methods have been renamed >- ServletRequestDataBinder contains a BindException now instead of deriving from it > >Typical application code should not be affected as we have kept deprecated methods. We recommend to migrate promptly though, as we intend to drop the deprecated methods before 1.0 final. See changes-M2-M3.txt for details. > >Regards, >Juergen > > |
|
From: <jue...@we...> - 2003-11-25 20:37:02
|
Looking forward, I'm keen on getting out RC1 in December, right before = Christmas if necessary - the goal as I see it is "this year". Our main = concern will be documentation, I guess, as everything else should just = be about bug-fixing and refining. If anyone wants to add a major new = feature, feel free to go ahead but please tell the group and hurry up = ;-) =20 One point to get right for RC1 is correct packaging of third-party = libraries. Like Hibernate, we should include the licenses of all = packages that we ship. And we should update to the current versions of = all libs. In particular, we need to pay attention to Hibernate 2.1: = IIRC, they switched to CGLIB2 in the 2.1 tree, so we should check if our = AOP framework can work with that too. After all, we have numerous users = combining Hibernate and Spring's declarative transaction management. =20 Agreement? Wishes? Complaints? =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Di 25.11.2003 12:47 An: spr...@li...; = spr...@li... Betreff: [Springframework-developer] Spring Framework 1.0 M3 released Hello everybody, I'm pleased to announce the release of Spring Framework 1.0 M3. This is = the fifth public release towards 1.0 final. As you can see in the = changelog, there have been lots of changes in this iteration. The next = release will be 1.0 RC1; we do not plan any further milestone releases. M3 introduces significant new features and enhancements, among them: - Type 3 IoC support in the bean factory (constructor resolution) - bean factory SPI interfaces (package bean.factory.config) - redesigned AOP API (more flexible pointcut handling etc) - reworked and optimized transaction manager implementations - fine-grained JDBC exception handling in the Hibernate support - reworked JDO support with a new JdoDialect strategy - reworked exception handling in the web framework - working Tiles example application included Some of the changes will need migration of existing code, most notably: - Controllers are now allowed to throw Exception (affecting = BaseCommandController and AbstractFormController) - some of BeanCommandController's methods have been renamed - ServletRequestDataBinder contains a BindException now instead of = deriving from it Typical application code should not be affected as we have kept = deprecated methods. We recommend to migrate promptly though, as we = intend to drop the deprecated methods before 1.0 final. See = changes-M2-M3.txt for details. Regards, Juergen ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <tri...@tr...> - 2003-11-25 16:44:57
|
Juerge, Website is now updated. Thomas Quoting "jürgen höller [werk3AT]" <jue...@we...>: > Thomas, can you please update the website accordingly? > > Juergen > > > ________________________________ > > Von: spr...@li... im Auftrag von > jürgen höller [werk3AT] > Gesendet: Di 25.11.2003 12:47 > An: spr...@li...; > spr...@li... > Betreff: [Springframework-developer] Spring Framework 1.0 M3 released > > > > Hello everybody, > > I'm pleased to announce the release of Spring Framework 1.0 M3. This is the > fifth public release towards 1.0 final. As you can see in the changelog, > there have been lots of changes in this iteration. The next release will be > 1.0 RC1; we do not plan any further milestone releases. > > M3 introduces significant new features and enhancements, among them: > - Type 3 IoC support in the bean factory (constructor resolution) > - bean factory SPI interfaces (package bean.factory.config) > - redesigned AOP API (more flexible pointcut handling etc) > - reworked and optimized transaction manager implementations > - fine-grained JDBC exception handling in the Hibernate support > - reworked JDO support with a new JdoDialect strategy > - reworked exception handling in the web framework > - working Tiles example application included > > Some of the changes will need migration of existing code, most notably: > - Controllers are now allowed to throw Exception (affecting > BaseCommandController and AbstractFormController) > - some of BeanCommandController's methods have been renamed > - ServletRequestDataBinder contains a BindException now instead of deriving > from it > > Typical application code should not be affected as we have kept deprecated > methods. We recommend to migrate promptly though, as we intend to drop the > deprecated methods before 1.0 final. See changes-M2-M3.txt for details. > > Regards, > Juergen > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Neill R. <nei...@ph...> - 2003-11-25 13:44:49
|
As a user, yes please. I was reading this doco when I first started = spring, wanting to findsome examples, and then lost the URL, and then = had to search theserverside look for it... -----Original Message----- From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20 Sent: 25 November 2003 13:24 To: spr...@li... Subject: Re: [Springframework-developer] Spring Framework 1.0 M3 = released Importance: Low Shouldn't we also link to Rod's TSS article = (http://www.theserverside.com/resources/article.jsp?l=3DSpringFramework) = from the documentation section? =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Di 25.11.2003 12:49 An: spr...@li... Betreff: Re: [Springframework-developer] Spring Framework 1.0 M3 = released Thomas, can you please update the website accordingly? Juergen ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Di 25.11.2003 12:47 An: spr...@li...; = spr...@li... Betreff: [Springframework-developer] Spring Framework 1.0 M3 released Hello everybody, I'm pleased to announce the release of Spring Framework 1.0 M3. This is = the fifth public release towards 1.0 final. As you can see in the = changelog, there have been lots of changes in this iteration. The next = release will be 1.0 RC1; we do not plan any further milestone releases. M3 introduces significant new features and enhancements, among them: - Type 3 IoC support in the bean factory (constructor resolution) - bean factory SPI interfaces (package bean.factory.config) - redesigned AOP API (more flexible pointcut handling etc) - reworked and optimized transaction manager implementations - fine-grained JDBC exception handling in the Hibernate support - reworked JDO support with a new JdoDialect strategy - reworked exception handling in the web framework - working Tiles example application included Some of the changes will need migration of existing code, most notably: - Controllers are now allowed to throw Exception (affecting = BaseCommandController and AbstractFormController) - some of BeanCommandController's methods have been renamed - ServletRequestDataBinder contains a BindException now instead of = deriving from it Typical application code should not be affected as we have kept = deprecated methods. We recommend to migrate promptly though, as we = intend to drop the deprecated methods before 1.0 final. See = changes-M2-M3.txt for details. Regards, Juergen ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does = SourceForge.net help you be more productive? Does it help you create = better code? SHARE THE LOVE, and help us help YOU! Click Here: = http://sourceforge.net/donate/ = _______________________________________________ Springframework-developer mailing list = Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does = SourceForge.net help you be more productive? Does it help you create = better code? SHARE THE LOVE, and help us help YOU! Click Here: = http://sourceforge.net/donate/ = _______________________________________________ Springframework-developer mailing list = Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does = SourceForge.net help you be more productive? Does it help you create = better code? SHARE THE LOVE, and help us help YOU! Click Here: = http://sourceforge.net/donate/ = _______________________________________________ Springframework-developer mailing list = Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-11-25 13:26:27
|
Shouldn't we also link to Rod's TSS article = (http://www.theserverside.com/resources/article.jsp?l=3DSpringFramework) = from the documentation section? =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Di 25.11.2003 12:49 An: spr...@li... Betreff: Re: [Springframework-developer] Spring Framework 1.0 M3 = released Thomas, can you please update the website accordingly? Juergen ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Di 25.11.2003 12:47 An: spr...@li...; = spr...@li... Betreff: [Springframework-developer] Spring Framework 1.0 M3 released Hello everybody, I'm pleased to announce the release of Spring Framework 1.0 M3. This is = the fifth public release towards 1.0 final. As you can see in the = changelog, there have been lots of changes in this iteration. The next = release will be 1.0 RC1; we do not plan any further milestone releases. M3 introduces significant new features and enhancements, among them: - Type 3 IoC support in the bean factory (constructor resolution) - bean factory SPI interfaces (package bean.factory.config) - redesigned AOP API (more flexible pointcut handling etc) - reworked and optimized transaction manager implementations - fine-grained JDBC exception handling in the Hibernate support - reworked JDO support with a new JdoDialect strategy - reworked exception handling in the web framework - working Tiles example application included Some of the changes will need migration of existing code, most notably: - Controllers are now allowed to throw Exception (affecting = BaseCommandController and AbstractFormController) - some of BeanCommandController's methods have been renamed - ServletRequestDataBinder contains a BindException now instead of = deriving from it Typical application code should not be affected as we have kept = deprecated methods. We recommend to migrate promptly though, as we = intend to drop the deprecated methods before 1.0 final. See = changes-M2-M3.txt for details. Regards, Juergen ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Darren D. <dda...@kg...> - 2003-11-25 13:22:51
|
just noticed this post in one of the forums which looks to be basically the same requirement.. http://sourceforge.net/forum/forum.php?thread_id=974391&forum_id=250339 > The addition of the setAttributesMap(Map) in AbstractView, and > Colin's new MethodInvokingFactoryBean actually combine quite well to > allow an arbitrary > (and possibly unmodifiable) business object to contribute model data > to one or more views in isolation of any controller that provides > the main model. Which is good, because this is something that would > be of great use to us here and which has been mentioned (admittedly > mainly by me) on this list a couple of times. -- Darren Davison Public Key: http://www.davison.uk.net/key.jsp |
|
From: Kopylenko, D. <dko...@ac...> - 2003-11-25 13:20:33
|
Not in use. +1 for removing Dmitriy. -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: Tuesday, November 25, 2003 8:12 AM To: spr...@li... Cc: spr...@li... Subject: [Springframework-user] BeanWrapper All, Anyone using the "event propagation" functionality of the org.springframework.beans.BeanWrapper/BeanWrapperImpl? I'm considering removing it to improve performance when repeatedly creating prototype beans, and to simplify the API and implementation of BeanWrapperImpl. I don't like features that aren't used. I can't think of a valid reason to use it myself now we have AOP interception, which can be used against any bean registered with Spring. The BeanWrapper propagation methods would also need support right through the BeanFactory classes to be easily used in practice. SO...if you object to me removing these methods before RC1, please let me know. Regards, Rod ____________________________________________________ Rod Johnson J2EE Consultant and Author +44 7973 409 132 rod...@in... Author of "Expert One-on-One J2EE Design and Development" (October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/ Founder, Spring Framework: http://www.springframework.org "Introducing the Spring Framework" (ServerSide article) http://www.theserverside.com/resources/article.jsp?l=SpringFramework ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-user mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-user |
|
From: Rod J. <rod...@in...> - 2003-11-25 13:12:51
|
All, Anyone using the "event propagation" functionality of the org.springframework.beans.BeanWrapper/BeanWrapperImpl? I'm considering removing it to improve performance when repeatedly creating prototype beans, and to simplify the API and implementation of BeanWrapperImpl. I don't like features that aren't used. I can't think of a valid reason to use it myself now we have AOP interception, which can be used against any bean registered with Spring. The BeanWrapper propagation methods would also need support right through the BeanFactory classes to be easily used in practice. SO...if you object to me removing these methods before RC1, please let me know. Regards, Rod ____________________________________________________ Rod Johnson J2EE Consultant and Author +44 7973 409 132 rod...@in... Author of "Expert One-on-One J2EE Design and Development" (October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/ Founder, Spring Framework: http://www.springframework.org "Introducing the Spring Framework" (ServerSide article) http://www.theserverside.com/resources/article.jsp?l=SpringFramework |
|
From: <jue...@we...> - 2003-11-25 11:51:58
|
Thomas, can you please update the website accordingly? =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Di 25.11.2003 12:47 An: spr...@li...; = spr...@li... Betreff: [Springframework-developer] Spring Framework 1.0 M3 released Hello everybody, I'm pleased to announce the release of Spring Framework 1.0 M3. This is = the fifth public release towards 1.0 final. As you can see in the = changelog, there have been lots of changes in this iteration. The next = release will be 1.0 RC1; we do not plan any further milestone releases. M3 introduces significant new features and enhancements, among them: - Type 3 IoC support in the bean factory (constructor resolution) - bean factory SPI interfaces (package bean.factory.config) - redesigned AOP API (more flexible pointcut handling etc) - reworked and optimized transaction manager implementations - fine-grained JDBC exception handling in the Hibernate support - reworked JDO support with a new JdoDialect strategy - reworked exception handling in the web framework - working Tiles example application included Some of the changes will need migration of existing code, most notably: - Controllers are now allowed to throw Exception (affecting = BaseCommandController and AbstractFormController) - some of BeanCommandController's methods have been renamed - ServletRequestDataBinder contains a BindException now instead of = deriving from it Typical application code should not be affected as we have kept = deprecated methods. We recommend to migrate promptly though, as we = intend to drop the deprecated methods before 1.0 final. See = changes-M2-M3.txt for details. Regards, Juergen ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-11-25 11:49:53
|
Hello everybody, =20 I'm pleased to announce the release of Spring Framework 1.0 M3. This is = the fifth public release towards 1.0 final. As you can see in the = changelog, there have been lots of changes in this iteration. The next = release will be 1.0 RC1; we do not plan any further milestone releases. =20 M3 introduces significant new features and enhancements, among them: - Type 3 IoC support in the bean factory (constructor resolution) - bean factory SPI interfaces (package bean.factory.config) - redesigned AOP API (more flexible pointcut handling etc) - reworked and optimized transaction manager implementations - fine-grained JDBC exception handling in the Hibernate support - reworked JDO support with a new JdoDialect strategy - reworked exception handling in the web framework - working Tiles example application included =20 Some of the changes will need migration of existing code, most notably: - Controllers are now allowed to throw Exception (affecting = BaseCommandController and AbstractFormController) - some of BeanCommandController's methods have been renamed - ServletRequestDataBinder contains a BindException now instead of = deriving from it Typical application code should not be affected as we have kept = deprecated methods. We recommend to migrate promptly though, as we = intend to drop the deprecated methods before 1.0 final. See = changes-M2-M3.txt for details. =20 Regards, Juergen =20 |
|
From: Darren D. <dda...@kg...> - 2003-11-25 09:34:24
|
The addition of the setAttributesMap(Map) in AbstractView, and Colin's new
MethodInvokingFactoryBean actually combine quite well to allow an arbitrary
(and possibly unmodifiable) business object to contribute model data to one or
more views in isolation of any controller that provides the main model. Which
is good, because this is something that would be of great use to us here and
which has been mentioned (admittedly mainly by me) on this list a couple of times.
There is a bit of an obstacle to it working the way we need though. Because
the bean is added to the view as a 'static attribute' it only ever gets
evaluated once before the view is cached by the resolver for the first time.
Is there any way we could mark an individual view with a property in
views.(properties|xml) that tells AbstractCachingViewResolver that the
staticAttributes should be re-evaluated (at least if they are of type
FactoryBean)?
It would need AbstractCachingViewResolver to be modified I guess along the
lines of;
private void reloadAttributes(View v) {
/*
1. get static attribute map from view
2. iterate over entries looking for entries of type FactoryBean
3. call addStaticAttribute() if of type FactoryBean (or force a call on
getObject())
*/
}
To prevent a general degradation of view efficiency, this method would be
called conditionally just prior to returning the view object in
AbstractCachingViewResolver.resolveViewName() if the view had been marked as
'dynamic' or whatever..
public final View resolveViewName(String viewName, Locale locale) throws
ServletException {
...
if (viewIsDynamic) reloadAttributes(view);
return view;
}
Any thoughts?
--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
|
|
From: Colin S. <col...@ex...> - 2003-11-25 02:42:28
|
Looks good to me... Kopylenko, Dmitry wrote: >Everyone, > >here are the revised Spring module names: > >* SpringAOP (aop framework) >* SpringCore (beans, context, core, util, validation) >* SpringTx (transaction) >* SpringDA (dao, jdbc, orm) [DA - Data Access] >* SpringWeb (web, ui) >* SpringJ2EE (ejb, jndi, mail, remoting) [jms, webservices, etc - later] >* SpringMetadata (metadata, enterpriseservices?) > >So, how does it look? > >Regards, >Dmitriy. > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Kopylenko, D. <dko...@ac...> - 2003-11-25 01:10:54
|
Everyone, here are the revised Spring module names: * SpringAOP (aop framework) * SpringCore (beans, context, core, util, validation) * SpringTx (transaction) * SpringDA (dao, jdbc, orm) [DA - Data Access] * SpringWeb (web, ui) * SpringJ2EE (ejb, jndi, mail, remoting) [jms, webservices, etc - later] * SpringMetadata (metadata, enterpriseservices?) So, how does it look? Regards, Dmitriy. |
|
From: Colin S. <col...@ex...> - 2003-11-24 12:37:17
|
W/regards to doing something with XmlWebApplicationContext, I didn't realize that some containers accept paths in ServletContext.getResource without the leading slash. (I wish containers would just stick to the spec, this sort of looseness just ends confusing things and killing portability). It would still be nice to get it to be able to load from the classpath too though. I wonder what the implications would be of just hitting ServletContext.getResource as the code does now, then the ClassLoader.getResource if the resource is not found in the first call? Probably it could lead to some situations where people pick up stuff they don't want. As far as adding a pseudo prefix to indicate classpath, that's an ok idea. The only issue with it is that as there is no real url handler in the system for that prefix, if anybody in some Java code tried to manipulate this as a real URL they'd get a MalformedUrlException as soon as they tried to construct the URL. However, I don't think this is an issue since in fact this value is not always a URL in any case. jürgen höller [werk3AT] wrote: >You don't need to add that slash for Hibernate's configuration file now: LocalSessionFactoryBean will automatically add the slash before passing it to Hibernate if you haven't specified it. Those checks for leading slashes were in there in all kinds of places: I've removed them everywhere besides in LocalSessionFactoryBean, as our own ClassLoaderUtils.getResourceAsStream does not need them anymore. > >We could go about other libs the same way: Prepend a leading slash or remove it before passing the path to the library, adapting to the way the library needs it, so that user-specified paths will work in any case. From the point of view of a Spring configuration, either style will work, no matter if interpreted by Spring or by the library. Note that we mainly load resources ourselves and feed them to the respective library anyway: For example, for JDO and Log4J. > >Regarding XmlWebApplicationContext: ServletContext.getResourceAsStream needs a leading slash according to the spec, that's why we add one if not there already. Most containers accept paths without leading slash too, though, for example Tomcat and Resin - but not Orion. It consider it generally a bit confusing that you need the slash for ServletContext, where the resource paths are interpreted as relative to the root in any case - while you must not use a leading slash for ClassLoader, where all resource paths are relative to the root too! > >Interpreting paths with leading slashes as ServletContext resources and without slashes as class path resources would be confusing, IMO. As mentioned above, many web app developers might be used to be able to load from the ServletContext with no leading slash, which wouldn't work with Spring then. We shouldn't rely on such ambiguous syntactic details to decide between two completely different ways of resource loading. > >Note that you can also specify URLs for ApplicationContext.getResourceAsStream, e.g. with a "file:" or "http:" prefix. So a cleaner way to support class path resources would probably be to define "classpath:" or the like as pseudo-prefix for URL-style paths. This way, there is only one meaning for non-URL paths in each context implementation, i.e. XmlWebApplicationContext always interprets them as ServletContext resource paths. > >Any other opinions on this? If yes, then please voice them today - we shouldn't delay M3 any further! > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Colin Sampaleanu >Gesendet: Mo 24.11.2003 00:54 >An: spr...@li... >Betreff: Re: [Springframework-developer] Classloading issue to resolve before M3 release! > > > >Unfortunately I don't agree that accepting both leading slashes and no >leading slashes is going to provide the least surprise. Hibernate is >Hibernate. If for some reason they decided to load via Class.getResource >instead of ClassLoader.getResource, I think they're wrong (because >they're not using the context classloader) but that's their business, >and at least they're consistent about it. In fact, they will fail if >they are given a path _without_ the leading slash. > >If we accept both to mean the same, that's ok for Spring itself, but >it's not consistent with the fact that most other java code handles the >two variants differently. And if you give a path to Spring, you then >have to think, is this for Spring itself, which will handle both ways, >or is it going to end up being fed to some lib, which needs it in one >way, or fed to another lib, which needs it in another way, and is it >going to be doctored by Spring, or go straight through? i.e. right now >for Hibernate, the fact that Spring takes both formats elsewhere doesn't >help me at all, I still have to think of Hibernate and add that slash. >I'd rather be consistent and say, Spring needs resource paths in >standard ClassLoader.getResource format, and that's it. Then if you have >a case where a path is not for Spring, but is fed straight through to >some other lib (like Hibernate), which uses Class.getResource instead of >ClassLoader.getResource, you either strongly document this special case, >or fix it up yourself... > >There is another consideration somewhat relating to this, and that is >the fact that currently XMLWebApplicationContext is hard-coded to add >(if not there already) a leading slash to all paths it is fed, and then >it uses ServletContext to load the defs, so the defs can only be loaded >off the web-context root. In this case, we could instead treat paths >which start with a leading slash as relating to ServletContext, and >paths which don't have a leading slash as relating to the context >classloader, with no interference. I've always thought it was an >unecessary limiation to not have XMLWebApplicationContext be able to >load contexts out of the classloader. > >Regards, >Colin > >jürgen höller [werk3AT] wrote: > > |
|
From: Colin S. <col...@ex...> - 2003-11-24 12:18:59
|
Those kinds of usages are pretty cool, or using it to get to simple static factory methods and the like, which was the original intent. On the other hand it's already happened to me that I've tried to abuse it in a sense; I ended up with a chained sequence of 6-7 method calls to initialize some static impl. vars in some sun classes. Then I looked at it, and said, this is so verbose, and only one aspect here will ever actually have to be configured (changed) in real life usage in my own app. So I ended up just adding a java class to do most of the init with and took the stuff out of the context. So once you have the power to do method calls, the temptation is there to do stuff in the context that is probably best left as java code, at least to the extent that it's way less work/less verbose. When/if we get some sort of expression language in there that will make things simpler, but I'm sure open up the possibility of even more abuse... Rod Johnson wrote: >Colin, > >This is a cool feature. I've just used it for the first time, and it makes a >couple of new idioms possible. > >For example, I've added a getStatsMixin() method to >ApartmentInvokerInterceptor which can optionally be used easily via a >MethodInvokingFactoryBean to create an Advisor, as in the test suite. > >Regards, >Rod > > |
|
From: MacMahon, M. <M.M...@em...> - 2003-11-24 12:01:30
|
Hi All,
The problem that I described in my previous email appears to be fixed in
the 1.0 M3 (prepared) release!
Thanks again,
Mark.
-----Original Message-----
From: MacMahon, Mark [mailto:M.M...@em...]
Sent: 21 November 2003 14:58
To: 'spr...@li...'
Subject: RE: [Springframework-developer] Intercepting a Prototype Bean
Hi Rod, all,
Thanks very much for the prompt and detailed replies.
I have tried to apply your suggested solution to my problem but am still
encountering the same issues
I.E the same TestTarget instance is being re-used for each invocation!
Have I misunderstood?
I have defined the following in applicationContext.xml
<!-- TestTarget implements the ITestTarget interface - one method foo() -->
<bean id="TestTarget" class="test.TestTarget" singleton="false">
</bean>
<!-- Transaction Interceptor Chain-->
<!-- Specified as a prototype (for mixin behaviour) -->
<bean id="MixinTransactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor"
singleton="false">
<property name="transactionManager"><ref
local="transactionManager"/></property>
<property name="transactionAttributeSource">
<value>test.ITestTarget.foo=PROPAGATION_REQUIRED</value>
</property>
</bean>
<!--Applies MixinTransactionInterceptor to TestTarget -->
<bean id="TestInterceptor"
class="org.springframework.aop.framework.ProxyFactoryBean" singleton="true">
<property
name="interceptorNames"><value>MixinTransactionInterceptor,TestTarget</value
></property>
<property name="singleton"><value>false</value></property>
</bean>
My test is as simple as it can get ;-)
public class TestTarget implements ITestTarget
{
private int invocationCount = 0;
public void foo()
{
System.err.println
(
"<<TestTarget:foo>> "+toString()+" Invocation Count is
"+(++invocationCount)
);
}
}
ITestTarget testInterceptor1 =
(ITestTarget)context.getBean("TestInterceptor");
ITestTarget testInterceptor2 =
(ITestTarget)context.getBean("TestInterceptor");
testInterceptor1.foo();
testInterceptor2.foo();
Output is
[java] <<TestTarget:foo>> test.TestTarget@e183e9 Invocation Count is 1
[java] <<TestTarget:foo>> test.TestTarget@e183e9 Invocation Count is 2
On a related note, I think it would be _nice_ to be able to define the
transaction behaviour in the same manner
adopted by TransactionProxyFactoryBean.
Also, is it possible to apply my MixinTransactionInterceptor to multiple
target classes
<property name="transactionAttributeSource">
<value>
test.ITestTarget.foo=PROPAGATION_REQUIRED
test.IOtherObject.bar=PROPAGATION_REQUIRED
</value>
</property>
Thanks again,
Mark
-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: 20 November 2003 17:29
To: spr...@li...
Subject: Re: [Springframework-developer] Intercepting a Prototype Bean
Mark,
> Is it possible to apply an interceptor to a prototype bean?
Yes.
> The prototype is stateful - i.e one per user
Yes, Spring supports mixins, ie one interceptor per mixin instance.
> I have defined the following in applicationContext.xml
>
>
> <bean id="TestTarget" class="test.MyTarget" singleton="false">
> </bean>
>
>
> <bean id="TestInterceptor"
>
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBe
> an" singleton="false">
> <property name="transactionManager"><ref
> local="transactionManager"/></property>
>
> <property name="target"><ref local="TestTarget"/></property>
>
>
> <property name="transactionAttributes">
> <props>
> <prop key="foo">PROPAGATION_REQUIRED</prop>
> </props>
> </property>
> </bean>
>
>
>
> When I invoke the method foo I get a ClassCastException
Not sure why this is happening but you may need to create the interceptor
chain manually to use a prototype, as TransactionProxyFactoryBean propably
assumes it's dealing with a singleton. So you need to create a chain that
includes:
- the name of your prototype
- the interceptor names, which may be singletons or prototypes as you
require. Use a prototype for mixin support.
The following example comes from the test suite, with minor changes to make
it more obvious:
<bean id="prototypeTarget"
class="org.springframework.aop.interceptor.SideEffectBean"
singleton="false">
<property name="count"><value>10</value></property>
</bean>
<!-- This can be a singleton or a prototype (for mixin behaviour) -->
<bean id="debugInterceptor"
class="org.springframework.aop.interceptor.DebugInterceptor">
</bean>
<bean id="prototype"
class="org.springframework.aop.framework.ProxyFactoryBean">
<!-- will automatically create invoker interceptor for the prototype -->
<property
name="interceptorNames"><value>debugInterceptor,prototypeTarget</value></pro
perty>
<!-- Note this -->
<property name="singleton"><value>false</value></property>
</bean>
There is a bug in M2 to do with prototype AOP handling, which is fixed in
the forthcoming M3. However I don't think it should affect you in such a
simple usage.
Regards,
Rod
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Rod J. <rod...@in...> - 2003-11-24 11:33:49
|
Colin, This is a cool feature. I've just used it for the first time, and it makes a couple of new idioms possible. For example, I've added a getStatsMixin() method to ApartmentInvokerInterceptor which can optionally be used easily via a MethodInvokingFactoryBean to create an Advisor, as in the test suite. Regards, Rod |
|
From: <jue...@we...> - 2003-11-24 10:40:00
|
Alef, =20 I hope you're feeling better again, and don't worry about the Tiles = example - it's already revised and now fully working in the standard = distribution, just like Petclinic and Countries (we do include = struts-1.1.jar now)! You can have a look at the current version in CVS = if you want. =20 To see the working Tiles example, generate a release zip via the = "release" target, build a tiles-example.war via = samples/tiles-example/warfile.bat in the extracted zip, and drop the war = into the webapps directory of a container. All of that should work = out-of-the-box now. =20 Juergen=20 =20 ________________________________ Von: spr...@li... im Auftrag = von Alef Arendsen (JTeam) Gesendet: Mo 24.11.2003 11:27 An: spr...@li... Betreff: RE: [Springframework-developer] 1.0 M3 prepared > C) We probably do need a document. The DTD has some > documentation in it. I'm working on the reference documentation (of which I'll be checking in another part this week). I'll see if I can do something about the structure of XML contexts as well... > Alef, could you give the tiles-example a final try? > I'm not keen on including struts.jar in the Spring > distribution, so the example should be prepared for > deployment with a manually added struts.jar. I've been heavily sick last weekend so unfortunately haven't been able to do anything :(((( Sorry... From one of your later comments I saw it was fixed already?? Alef ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-11-24 10:26:54
|
> C) We probably do need a document. The DTD has some > documentation in it. I'm working on the reference documentation (of which I'll be checking in another part this week). I'll see if I can do something about the structure of XML contexts as well... > Alef, could you give the tiles-example a final try? > I'm not keen on including struts.jar in the Spring > distribution, so the example should be prepared for > deployment with a manually added struts.jar. I've been heavily sick last weekend so unfortunately haven't been able to do anything :(((( Sorry... From one of your later comments I saw it was fixed already?? Alef |
|
From: <yan...@ya...> - 2003-11-24 10:06:52
|
>Another Spring reference - this time in HiveMind thread: >http://www.theserverside.com/home/thread.jsp?thread_id=22371 tapestry focus the concept of "distributed configuration" by Howard. But what is "distributed configuration" ? the concept is very difficult :it is quite beyond me. ===== Give my best to you! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: <jue...@we...> - 2003-11-24 09:28:49
|
The summary of changes in the web frame work is in changes-M2-M3.txt, = which now includes the summary of AOP changes too. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: So 23.11.2003 13:35 An: spr...@li... Betreff: Re: [Springframework-developer] 1.0 M3 prepared I'd like to encourage everybody to try the current snapshot for Spring = web MVC applications. As I've said in the corresponding mails, there = shouldn't be any changes necessary for standard stuff, but you might = need to adapt thrown exceptions if invoking controller super class = methods - trivial to change, simply declare "throws Exception" if = necessary. Whoever likes to play around can also have a look at the = HandlerExceptionResolver stuff. I've added an example for it to = Petclinic, forwarding DataAccessExceptions and TransactionExceptions to = a special MVC-managed error page. For existing apps, simply don't worry = about it. The Tiles example does now work out-of-the-box in the generated release = distribution. Simply invoke warfile.bat and drop the war file from the = dist directory into your container's webapps directory, just like with = Countries and Petclinic. I'll prepare a short summary of deprecations and potentially = incompatible changes (probably collecting them together in one file with = Rod's summary of AOP changes), as there are quite a few in the meantime. Juergen ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: So 23.11.2003 01:44 An: spr...@li... Betreff: Re: [Springframework-developer] 1.0 M3 prepared FYI, I've already committed the renaming from ListableBeanFactoryImpl to = DefaultListableBeanFactory. The web MVC exception stuff will follow = tomorrow. I've also reworked the Tiles example, using = org.springframework.samples.tiles as package now, and auto-detecting the = Tiles DTD. The FileNameViewController has now moved to = org.springframework.web.servlet.mvc. And I've changed my mind: I do like = to include struts-1.1.jar and commons-digester.jar now, for an = out-of-the-box working example. It already annoys me having to copy = those files in for testing, so consider a new user... I've just modified our build script to generate two release zips: = spring-framework-1.0-m3.zip (~5600 KB) and = spring-framework-1.0-m3-samples.zip (~5400 KB). Both use = spring-framework-1.0-m3 as path in the zip, for convenient extraction to = the same location. The former contains dist, docs, lib/aop-alliance, = lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the = latter contains samples and the additional libs necessary for building = and running them. What do you think? Should I commit the changed build script and use it = for the M3 release? I believe it would make sense to split the release = into those two files, as 11 MB is already a bit large for a single = distribution. Juergen ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Sa 22.11.2003 00:57 An: spr...@li... Betreff: Re: [Springframework-developer] 1.0 M3 prepared j=FCrgen h=F6ller [werk3AT] wrote: >Everybody, > >I've just prepared the release as far as possible: fixed all javadoc = errors, added missing package javadocs, tested the samples. All tests = for shipped components pass on my machine (when running via Ant). > >The TLD is now loaded from the spring.jar file, referenced via the = default URI http://www.springframework.org/tags (analogous to Struts and = JSTL). BaseCommandController uses setCommandName now, with setBeanName = being deprecated. > >Whoever wants to give it a try, fetch the latest CVS contents, run the = release target, and "play user" with spring-framework-1.0-m3.zip (it's = in the target/release directrory): unzip it, browse through the docs, = build the sample wars (call ant warfile or warfile.bat) and drop them = into your container's webapps directory. > >Alef, could you give the tiles-example a final try? I'm not keen on = including struts.jar in the Spring distribution, so the example should = be prepared for deployment with a manually added struts.jar. > >A final note on a further naming issue: I'm not entirely happy with = "ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the* = implementation of BeanWrapper, hardly any chance for alternative = implementations - the interface is rather a simplified API for it. But = ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with = registration methods for a specific properties format; this seems to be = a different case to me. > >So wouldn't it be more appropriate to call it = "DefaultListableBeanFactory"? That name change should not affect typical = applications anyway but just "power users" who should be willing to = migrate via a simple class name change. I quite strongly prefer this = name to "ListableBeanFactoryImpl", actually. If we agree on the new = name, let's better change it now instead of in the 1.0 RC phase. > > > I am ok with the name change, as it does make sense. Btw, as per another email, I have added a new MethodCallFactoryBean class. It should be totally ok for this release, as no other code was touched, and there is a full unit test. Regards, Colin ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-11-24 09:26:23
|
You don't need to add that slash for Hibernate's configuration file now: =
LocalSessionFactoryBean will automatically add the slash before passing =
it to Hibernate if you haven't specified it. Those checks for leading =
slashes were in there in all kinds of places: I've removed them =
everywhere besides in LocalSessionFactoryBean, as our own =
ClassLoaderUtils.getResourceAsStream does not need them anymore.
=20
We could go about other libs the same way: Prepend a leading slash or =
remove it before passing the path to the library, adapting to the way =
the library needs it, so that user-specified paths will work in any =
case. From the point of view of a Spring configuration, either style =
will work, no matter if interpreted by Spring or by the library. Note =
that we mainly load resources ourselves and feed them to the respective =
library anyway: For example, for JDO and Log4J.
=20
Regarding XmlWebApplicationContext: ServletContext.getResourceAsStream =
needs a leading slash according to the spec, that's why we add one if =
not there already. Most containers accept paths without leading slash =
too, though, for example Tomcat and Resin - but not Orion. It consider =
it generally a bit confusing that you need the slash for ServletContext, =
where the resource paths are interpreted as relative to the root in any =
case - while you must not use a leading slash for ClassLoader, where all =
resource paths are relative to the root too!
=20
Interpreting paths with leading slashes as ServletContext resources and =
without slashes as class path resources would be confusing, IMO. As =
mentioned above, many web app developers might be used to be able to =
load from the ServletContext with no leading slash, which wouldn't work =
with Spring then. We shouldn't rely on such ambiguous syntactic details =
to decide between two completely different ways of resource loading.
=20
Note that you can also specify URLs for =
ApplicationContext.getResourceAsStream, e.g. with a "file:" or "http:" =
prefix. So a cleaner way to support class path resources would probably =
be to define "classpath:" or the like as pseudo-prefix for URL-style =
paths. This way, there is only one meaning for non-URL paths in each =
context implementation, i.e. XmlWebApplicationContext always interprets =
them as ServletContext resource paths.
=20
Any other opinions on this? If yes, then please voice them today - we =
shouldn't delay M3 any further!
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mo 24.11.2003 00:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Classloading issue to resolve =
before M3 release!
Unfortunately I don't agree that accepting both leading slashes and no
leading slashes is going to provide the least surprise. Hibernate is
Hibernate. If for some reason they decided to load via Class.getResource
instead of ClassLoader.getResource, I think they're wrong (because
they're not using the context classloader) but that's their business,
and at least they're consistent about it. In fact, they will fail if
they are given a path _without_ the leading slash.
If we accept both to mean the same, that's ok for Spring itself, but
it's not consistent with the fact that most other java code handles the
two variants differently. And if you give a path to Spring, you then
have to think, is this for Spring itself, which will handle both ways,
or is it going to end up being fed to some lib, which needs it in one
way, or fed to another lib, which needs it in another way, and is it
going to be doctored by Spring, or go straight through? i.e. right now
for Hibernate, the fact that Spring takes both formats elsewhere doesn't
help me at all, I still have to think of Hibernate and add that slash.
I'd rather be consistent and say, Spring needs resource paths in
standard ClassLoader.getResource format, and that's it. Then if you have
a case where a path is not for Spring, but is fed straight through to
some other lib (like Hibernate), which uses Class.getResource instead of
ClassLoader.getResource, you either strongly document this special case,
or fix it up yourself...
There is another consideration somewhat relating to this, and that is
the fact that currently XMLWebApplicationContext is hard-coded to add
(if not there already) a leading slash to all paths it is fed, and then
it uses ServletContext to load the defs, so the defs can only be loaded
off the web-context root. In this case, we could instead treat paths
which start with a leading slash as relating to ServletContext, and
paths which don't have a leading slash as relating to the context
classloader, with no interference. I've always thought it was an
unecessary limiation to not have XMLWebApplicationContext be able to
load contexts out of the classloader.
Regards,
Colin
j=FCrgen h=F6ller [werk3AT] wrote:
>Colin,
>
>I've been messing around with that myself for a while, and have also =
modified that ClassLoaderUtils method. I didn't realize that =
ClassLoader.getResourceAsStream does not accept leading slashes! - I =
thought they would work as absolute paths with both =
Class.getResourceAsStream and ClassLoader.getResourceAsStream.
>
>As for the context class loader, you're right that we should be able to =
rely on it in any case anyway. ClassLoaderUtils.getResourceAsStream was =
intended as framework-internal class anyway: Nowhere within the =
framework does loading relative to a framework class make any sense.
>
>It may make sense though to accept leading slashes in paths, as many =
callers don't want to worry about whether the path gets interpreted by =
Class or ClassLoader. For example, Hibernate's Configuration object =
needs the slash, as it loads via =
Environment.class.getResourceAsStream...
>
>To stick to the principle of least surprise, I strongly vote for =
treating "/a/b/myresource" the same as "a/b/myresource". This way, =
callers don't need to worry about the actual loading strategy. They can =
stick to the latter pattern, which is correct for ClassLoader usage, but =
also the former, for example if used to it from Hibernate.
>
>I've just committed that fix. Does that work for you too?
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>Gesendet: So 23.11.2003 21:37
>An: spr...@li...
>Betreff: [Springframework-developer] Classloading issue to resolve =
before M3 release!
>
>
>
>I just figured out that we have an issue with the existing code in
>ClassloaderUtils.getResourceAsStream, which is used in a number of =
places.
>
>Whoever wrote the original method:
>
> public static InputStream getResourceAsStream(Class clazz, String
>name) {
> ClassLoader ccl =3D =
Thread.currentThread().getContextClassLoader();
> InputStream in =3D null;
> if (ccl !=3D null) {
> in =3D ccl.getResourceAsStream(name);
> }
> if (in =3D=3D null) {
> in =3D clazz.getResourceAsStream(name);
> }
> return in;
> }
>
>did not realize that ClassLoader.getResourceAsStream and
>Class.getResourceAsStream do _not_ behave the same way w/regards to the
>path this is supplied to them.
>
>Class.getResource, expects to be given a path which is either relative
>or absolute to that class, as indicated by a leading /. If there is a
>leading slash, it strips off that slash, then passes on the request to
>its classloader (ie it calls ClassLoader.getResource). If there is no
>slash, it prepends the class package (without a leading slash) to the
>specified path, then calls getResource on its classloader.
>ClassLoader.getResource, on the other hand, expects that it is given
>only absolute paths, _without_ a leading slash. And it will fail if
>there is a leading slash.
>
>As such, if the code above is called with a path that is correct for =
the
>call to the context classloader (ie no leading slash), it will be
>incorrect for the call to class.getResource (as it will be considered
>relative). If it is called with code that is fully qualified/absolute
>and correct for the class.getResurce (ie it has a leading slash), it
>will always fail for the context classloader getResource call.
>
>Not good... Now this code is used in a number of places, usually with
>'/' prepended on the actual path. That is, the code assumes the =
resource
>lookup behaves in a similar fashion to Class.getResource, not
>ClassLoader.getResource. In that respect, the solution of 'least
>surpirse' is to treat the context classloader case the same. Even =
though
>it doesn't actually use the class package, if the path doesn't start
>with '/', it should be assumed to be relative and added to the =
specified
>resource path. Then this should be documented more explicitly (ie that
>it behaves like Class.getResource, not ClassLoader.getResource).
>
>Then, this could be deprecated, and we could make a prefered variation
>of getResource which doesn't take a class argument, just a resource
>path, and it would simply behave as the existing
>ClassLoader.getResource. From what I know, except in Java 1.1, the
>context classloader is always safe to use. (do we need Java 1.1
>compatibility here?)
>
>Then there is the question of classPackageAsResourcePath, which I
>originally wrote, but actually is only really correct when then used to
>call the current ClassLoaderUtils.getResourceAsStream or
>Class.getResourceAsStream. At a minimum, it should be documented, but I
>think it would be cleaner to not have it prepend a leading slash at =
all,
>so it could be fed to the regular ClassLoader.getResource.
>
>Finally, I think it possibly breaks the principal of least surprise =
that
>in most places (like ClassPathXmlApplicationContext or the web xml
>application context), we take resource paths and assume that
> a/b/c/d/123.abc
>is the same thing as
> /a/b/c/d/123.abc
>
>That is not how ClassLoader.getResource treats things, and that's not
>how Class.getResource treats things, so why are we doing it? At a
>minimum, it should be strongly documented, but I think it's simpler to
>just accept the first form only, to be like classloader resource
>specifications in other java apps/libs. This would obviously break some
>existing code. In fact, we even usually add the leading / right now
>automatically if it's not there.
>
>What do you guys think?
>=20
>
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2003-11-24 08:27:39
|
Rob, =20 Indeed, the "mappedHandlers" feature is exaxtly meant for restricting = the defined exception mappings of this resolver to the given set of = handlers. The handler implementations, be it Controller or any = convenience base class, do not have to be aware of it then. Such = explicit support is much simpler than having to set up an AOP proxy just = for this, I agree. =20 Yes, the exception class names will be checked via isAssignableFrom. You = can thus specify a base class and will catch all subclasses with it too. = Regarding an example, you can have a look at Petclinic in M3, as soon as = it is out. It forwards all DataAccessExceptions and = TransactionExceptions to some custom MVC-managed error page. =20 I agree that we need to document all those features: Actually, I'm quite = keen on a feature freeze for 1.0 as soon as possible to facilitate this. = I personally don't plan any further features; I know that Rod intends to = do polish the AOP convenience classes a bit. So if we don't encounter = any obstacles, RC1 should be out early December - the main difference to = M3 being better docs and more examples rather than new features. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Rob Butler Gesendet: Mo 24.11.2003 00:34 An: spr...@li... Betreff: Re: [Springframework-developer] MVC Exception Handling It sounds like Jurgen may have added the functionality I described = above: > A SimpleMappingExceptionResolver allows to map fully qualified = exception > class names (including base classes) to view names, restricting its mappings > to a certain list of handlers to be set as bean references to the "mappedHandlers" > property. Multiple resolver instances can thus define distinct = mappings for different > handlers. A generic one without mapped handlers can be the last in the ordered > chain, providing fallback resolution. So does "..including base classes.." mean that it will handle the = subclassed execeptions (instance of or isassignable) as I suggest above? It sounds as if the capability to have a "default" and "over-ridding" exception / view mappings has already been added. : ) I think it would be great if some examples of how to set this up could = be created as well. You guys are doing an awesome job of adding features / functionality but I think the documentation is having a more difficult = time of keeping up. Later Rob ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2003-11-24 00:28:43
|
I've modified ClassLoaderUtils.classPackageAsResourcePath to return a
path value without automatically adding a leading slash, which it
previously did. This change will allow the result to be fed to
ClassLoader.getResource, or also Class.getResource by prepending a
slash. I only added the original code a month and a half ago, with no
internal usage in Spring, and I doubt very many people are using it
externally yet. Even then, if they are feeding the result back to Spring
things will still work, so hopefully nobody will be affected.
Colin Sampaleanu wrote:
> Unfortunately I don't agree that accepting both leading slashes and no
> leading slashes is going to provide the least surprise. Hibernate is
> Hibernate. If for some reason they decided to load via
> Class.getResource instead of ClassLoader.getResource, I think they're
> wrong (because they're not using the context classloader) but that's
> their business, and at least they're consistent about it. In fact,
> they will fail if they are given a path _without_ the leading slash.
>
> If we accept both to mean the same, that's ok for Spring itself, but
> it's not consistent with the fact that most other java code handles
> the two variants differently. And if you give a path to Spring, you
> then have to think, is this for Spring itself, which will handle both
> ways, or is it going to end up being fed to some lib, which needs it
> in one way, or fed to another lib, which needs it in another way, and
> is it going to be doctored by Spring, or go straight through? i.e.
> right now for Hibernate, the fact that Spring takes both formats
> elsewhere doesn't help me at all, I still have to think of Hibernate
> and add that slash. I'd rather be consistent and say, Spring needs
> resource paths in standard ClassLoader.getResource format, and that's
> it. Then if you have a case where a path is not for Spring, but is fed
> straight through to some other lib (like Hibernate), which uses
> Class.getResource instead of ClassLoader.getResource, you either
> strongly document this special case, or fix it up yourself...
>
> There is another consideration somewhat relating to this, and that is
> the fact that currently XMLWebApplicationContext is hard-coded to add
> (if not there already) a leading slash to all paths it is fed, and
> then it uses ServletContext to load the defs, so the defs can only be
> loaded off the web-context root. In this case, we could instead treat
> paths which start with a leading slash as relating to ServletContext,
> and paths which don't have a leading slash as relating to the context
> classloader, with no interference. I've always thought it was an
> unecessary limiation to not have XMLWebApplicationContext be able to
> load contexts out of the classloader.
>
> Regards,
> Colin
>
> jürgen höller [werk3AT] wrote:
>
>> Colin,
>>
>> I've been messing around with that myself for a while, and have also
>> modified that ClassLoaderUtils method. I didn't realize that
>> ClassLoader.getResourceAsStream does not accept leading slashes! - I
>> thought they would work as absolute paths with both
>> Class.getResourceAsStream and ClassLoader.getResourceAsStream.
>>
>> As for the context class loader, you're right that we should be able
>> to rely on it in any case anyway.
>> ClassLoaderUtils.getResourceAsStream was intended as
>> framework-internal class anyway: Nowhere within the framework does
>> loading relative to a framework class make any sense.
>>
>> It may make sense though to accept leading slashes in paths, as many
>> callers don't want to worry about whether the path gets interpreted
>> by Class or ClassLoader. For example, Hibernate's Configuration
>> object needs the slash, as it loads via
>> Environment.class.getResourceAsStream...
>>
>> To stick to the principle of least surprise, I strongly vote for
>> treating "/a/b/myresource" the same as "a/b/myresource". This way,
>> callers don't need to worry about the actual loading strategy. They
>> can stick to the latter pattern, which is correct for ClassLoader
>> usage, but also the former, for example if used to it from Hibernate.
>>
>> I've just committed that fix. Does that work for you too?
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag
>> von Colin Sampaleanu
>> Gesendet: So 23.11.2003 21:37
>> An: spr...@li...
>> Betreff: [Springframework-developer] Classloading issue to resolve
>> before M3 release!
>>
>>
>>
>> I just figured out that we have an issue with the existing code in
>> ClassloaderUtils.getResourceAsStream, which is used in a number of
>> places.
>>
>> Whoever wrote the original method:
>>
>> public static InputStream getResourceAsStream(Class clazz, String
>> name) {
>> ClassLoader ccl = Thread.currentThread().getContextClassLoader();
>> InputStream in = null;
>> if (ccl != null) {
>> in = ccl.getResourceAsStream(name);
>> }
>> if (in == null) {
>> in = clazz.getResourceAsStream(name);
>> }
>> return in;
>> }
>>
>> did not realize that ClassLoader.getResourceAsStream and
>> Class.getResourceAsStream do _not_ behave the same way w/regards to the
>> path this is supplied to them.
>>
>> Class.getResource, expects to be given a path which is either relative
>> or absolute to that class, as indicated by a leading /. If there is a
>> leading slash, it strips off that slash, then passes on the request to
>> its classloader (ie it calls ClassLoader.getResource). If there is no
>> slash, it prepends the class package (without a leading slash) to the
>> specified path, then calls getResource on its classloader.
>> ClassLoader.getResource, on the other hand, expects that it is given
>> only absolute paths, _without_ a leading slash. And it will fail if
>> there is a leading slash.
>>
>> As such, if the code above is called with a path that is correct for the
>> call to the context classloader (ie no leading slash), it will be
>> incorrect for the call to class.getResource (as it will be considered
>> relative). If it is called with code that is fully qualified/absolute
>> and correct for the class.getResurce (ie it has a leading slash), it
>> will always fail for the context classloader getResource call.
>>
>> Not good... Now this code is used in a number of places, usually with
>> '/' prepended on the actual path. That is, the code assumes the resource
>> lookup behaves in a similar fashion to Class.getResource, not
>> ClassLoader.getResource. In that respect, the solution of 'least
>> surpirse' is to treat the context classloader case the same. Even though
>> it doesn't actually use the class package, if the path doesn't start
>> with '/', it should be assumed to be relative and added to the specified
>> resource path. Then this should be documented more explicitly (ie that
>> it behaves like Class.getResource, not ClassLoader.getResource).
>>
>> Then, this could be deprecated, and we could make a prefered variation
>> of getResource which doesn't take a class argument, just a resource
>> path, and it would simply behave as the existing
>> ClassLoader.getResource. From what I know, except in Java 1.1, the
>> context classloader is always safe to use. (do we need Java 1.1
>> compatibility here?)
>>
>> Then there is the question of classPackageAsResourcePath, which I
>> originally wrote, but actually is only really correct when then used to
>> call the current ClassLoaderUtils.getResourceAsStream or
>> Class.getResourceAsStream. At a minimum, it should be documented, but I
>> think it would be cleaner to not have it prepend a leading slash at all,
>> so it could be fed to the regular ClassLoader.getResource.
>>
>> Finally, I think it possibly breaks the principal of least surprise that
>> in most places (like ClassPathXmlApplicationContext or the web xml
>> application context), we take resource paths and assume that
>> a/b/c/d/123.abc
>> is the same thing as
>> /a/b/c/d/123.abc
>>
>> That is not how ClassLoader.getResource treats things, and that's not
>> how Class.getResource treats things, so why are we doing it? At a
>> minimum, it should be strongly documented, but I think it's simpler to
>> just accept the first form only, to be like classloader resource
>> specifications in other java apps/libs. This would obviously break some
>> existing code. In fact, we even usually add the leading / right now
>> automatically if it's not there.
>>
>> What do you guys think?
>>
>
|
|
From: Colin S. <col...@ex...> - 2003-11-23 23:54:03
|
Unfortunately I don't agree that accepting both leading slashes and no
leading slashes is going to provide the least surprise. Hibernate is
Hibernate. If for some reason they decided to load via Class.getResource
instead of ClassLoader.getResource, I think they're wrong (because
they're not using the context classloader) but that's their business,
and at least they're consistent about it. In fact, they will fail if
they are given a path _without_ the leading slash.
If we accept both to mean the same, that's ok for Spring itself, but
it's not consistent with the fact that most other java code handles the
two variants differently. And if you give a path to Spring, you then
have to think, is this for Spring itself, which will handle both ways,
or is it going to end up being fed to some lib, which needs it in one
way, or fed to another lib, which needs it in another way, and is it
going to be doctored by Spring, or go straight through? i.e. right now
for Hibernate, the fact that Spring takes both formats elsewhere doesn't
help me at all, I still have to think of Hibernate and add that slash.
I'd rather be consistent and say, Spring needs resource paths in
standard ClassLoader.getResource format, and that's it. Then if you have
a case where a path is not for Spring, but is fed straight through to
some other lib (like Hibernate), which uses Class.getResource instead of
ClassLoader.getResource, you either strongly document this special case,
or fix it up yourself...
There is another consideration somewhat relating to this, and that is
the fact that currently XMLWebApplicationContext is hard-coded to add
(if not there already) a leading slash to all paths it is fed, and then
it uses ServletContext to load the defs, so the defs can only be loaded
off the web-context root. In this case, we could instead treat paths
which start with a leading slash as relating to ServletContext, and
paths which don't have a leading slash as relating to the context
classloader, with no interference. I've always thought it was an
unecessary limiation to not have XMLWebApplicationContext be able to
load contexts out of the classloader.
Regards,
Colin
jürgen höller [werk3AT] wrote:
>Colin,
>
>I've been messing around with that myself for a while, and have also modified that ClassLoaderUtils method. I didn't realize that ClassLoader.getResourceAsStream does not accept leading slashes! - I thought they would work as absolute paths with both Class.getResourceAsStream and ClassLoader.getResourceAsStream.
>
>As for the context class loader, you're right that we should be able to rely on it in any case anyway. ClassLoaderUtils.getResourceAsStream was intended as framework-internal class anyway: Nowhere within the framework does loading relative to a framework class make any sense.
>
>It may make sense though to accept leading slashes in paths, as many callers don't want to worry about whether the path gets interpreted by Class or ClassLoader. For example, Hibernate's Configuration object needs the slash, as it loads via Environment.class.getResourceAsStream...
>
>To stick to the principle of least surprise, I strongly vote for treating "/a/b/myresource" the same as "a/b/myresource". This way, callers don't need to worry about the actual loading strategy. They can stick to the latter pattern, which is correct for ClassLoader usage, but also the former, for example if used to it from Hibernate.
>
>I've just committed that fix. Does that work for you too?
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: So 23.11.2003 21:37
>An: spr...@li...
>Betreff: [Springframework-developer] Classloading issue to resolve before M3 release!
>
>
>
>I just figured out that we have an issue with the existing code in
>ClassloaderUtils.getResourceAsStream, which is used in a number of places.
>
>Whoever wrote the original method:
>
> public static InputStream getResourceAsStream(Class clazz, String
>name) {
> ClassLoader ccl = Thread.currentThread().getContextClassLoader();
> InputStream in = null;
> if (ccl != null) {
> in = ccl.getResourceAsStream(name);
> }
> if (in == null) {
> in = clazz.getResourceAsStream(name);
> }
> return in;
> }
>
>did not realize that ClassLoader.getResourceAsStream and
>Class.getResourceAsStream do _not_ behave the same way w/regards to the
>path this is supplied to them.
>
>Class.getResource, expects to be given a path which is either relative
>or absolute to that class, as indicated by a leading /. If there is a
>leading slash, it strips off that slash, then passes on the request to
>its classloader (ie it calls ClassLoader.getResource). If there is no
>slash, it prepends the class package (without a leading slash) to the
>specified path, then calls getResource on its classloader.
>ClassLoader.getResource, on the other hand, expects that it is given
>only absolute paths, _without_ a leading slash. And it will fail if
>there is a leading slash.
>
>As such, if the code above is called with a path that is correct for the
>call to the context classloader (ie no leading slash), it will be
>incorrect for the call to class.getResource (as it will be considered
>relative). If it is called with code that is fully qualified/absolute
>and correct for the class.getResurce (ie it has a leading slash), it
>will always fail for the context classloader getResource call.
>
>Not good... Now this code is used in a number of places, usually with
>'/' prepended on the actual path. That is, the code assumes the resource
>lookup behaves in a similar fashion to Class.getResource, not
>ClassLoader.getResource. In that respect, the solution of 'least
>surpirse' is to treat the context classloader case the same. Even though
>it doesn't actually use the class package, if the path doesn't start
>with '/', it should be assumed to be relative and added to the specified
>resource path. Then this should be documented more explicitly (ie that
>it behaves like Class.getResource, not ClassLoader.getResource).
>
>Then, this could be deprecated, and we could make a prefered variation
>of getResource which doesn't take a class argument, just a resource
>path, and it would simply behave as the existing
>ClassLoader.getResource. From what I know, except in Java 1.1, the
>context classloader is always safe to use. (do we need Java 1.1
>compatibility here?)
>
>Then there is the question of classPackageAsResourcePath, which I
>originally wrote, but actually is only really correct when then used to
>call the current ClassLoaderUtils.getResourceAsStream or
>Class.getResourceAsStream. At a minimum, it should be documented, but I
>think it would be cleaner to not have it prepend a leading slash at all,
>so it could be fed to the regular ClassLoader.getResource.
>
>Finally, I think it possibly breaks the principal of least surprise that
>in most places (like ClassPathXmlApplicationContext or the web xml
>application context), we take resource paths and assume that
> a/b/c/d/123.abc
>is the same thing as
> /a/b/c/d/123.abc
>
>That is not how ClassLoader.getResource treats things, and that's not
>how Class.getResource treats things, so why are we doing it? At a
>minimum, it should be strongly documented, but I think it's simpler to
>just accept the first form only, to be like classloader resource
>specifications in other java apps/libs. This would obviously break some
>existing code. In fact, we even usually add the leading / right now
>automatically if it's not there.
>
>What do you guys think?
>
>
|
1239 messages has been excluded from this view by a project administrator.
