Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-11-23 00:46:52
|
FYI, I've already committed the renaming from ListableBeanFactoryImpl to = DefaultListableBeanFactory. The web MVC exception stuff will follow = tomorrow. =20 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... =20 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. =20 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. =20 Juergen =20 ________________________________ 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. > >=20 > 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 |
|
From: <jue...@we...> - 2003-11-23 11:42:51
|
A) OK, I've scrapped the distinction between main download and samples = for the time being. An 11 MB download isn't that large, after all. =20 B) Same as Rod, personally - for that kind of jar management, version = numbers are rather a nuisance, as you can't simply do a drop-in update = but have to do a remove plus an add. We include the actual Spring = version number as "Spring-Version" manifest attribute in = spring.jar/spring-beans.jar/spring-jdbc.jar/spring-context.jar, BTW. =20 C) Is there really no explicit documentation on it? Funnily enough, = noone has asked for it yet... The DTD is pretty self-explanatory and = enriched with comments, so it can serve as transitional documentation, I = guess. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Rod Johnson Gesendet: So 23.11.2003 10:16 An: spr...@li... Betreff: Re: [Springframework-developer] 1.0 M3 prepared A) I'm inclined to agree. I don't think a few megs are significant. It = also makes it harder to work out real download numbers. B) Tough question. While it is nice to know what version things are, in = my projects as an end user I tend to rely on CVS to manage versioning. E.g. = my manifest classpath, constructed in the build script, might reference aopalliance.jar and I would rely on source control to ensure that it was = the correct version for my source. (Of course without EJB, a manifest = classpath isn't usually needed.) Maybe we should survey what other projects do (or go Maven-friendly). C) We probably do need a document. The DTD has some documentation in it. Regards, Rod ----- Original Message ----- From: "Mike Cannon-Brookes" <mi...@at...> To: "Spring Developer" <spr...@li...> Sent: Sunday, November 23, 2003 5:38 AM Subject: Re: [Springframework-developer] 1.0 M3 prepared Can I make some suggestions before the release? A) ship all source with the release, including samples. I don't see why = we need multiple ZIPs? It just complicates things and will frustrate users trying out spring IMHO. Noone really cares if it's 11MB do they? = (apologies if this is an old already discussed issue - I'm just not sure the reason = for two JARs) B) Can we please, please, please version the JARs shipped? Eg aopalliance.jar is useless for people building apps, what version is it? Managing dependencies explicitly is important - make it aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS etc. C) On a slightly related note, I couldn't find any docs (maybe I'm = blind) on the exact syntax of the applicationContext.xml file? (ie how to set = lists, booleans etc) Cheers, Mike On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned = the words: > +1 for including the sample source in the base download. It's good as = a > reference. I have updated the MVC step-by-step document to reflect = the need > to > download both zips. > > Thomas > > Quoting Colin Sampaleanu <col...@ex...>: > >> j=FCrgen h=F6ller [werk3AT] wrote: >> >>> 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 >>> >>> >> It probably makes sense to split things up this way. If somebody = doesn't >> care about the libs for the samples it's a drag to pull them down = each >> release. Maybe it would make sense though to still include _sources_ = for >> the samples even with the first jar. Sample sources sometimes help = you >> figure stuff out that is not really related. I know that when I was >> initially looking at Spring and figuring out Application Contexts, I >> looked at all the contexts in all the samples, even if I had no = interest >> at that time in actually building those samples or using those parts = of >> Spring (like the MVC). >> >> 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 ------------------------------------------------------- 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: Mike Cannon-B. <mi...@at...> - 2003-11-23 12:10:42
|
> A) OK, I've scrapped the distinction between main download and samples fo= r the > time being. An 11 MB download isn't that large, after all. Cool. =20 > B) Same as Rod, personally - for that kind of jar management, version num= bers > are rather a nuisance, as you can't simply do a drop-in update but have t= o do > a remove plus an add. We include the actual Spring version number as > "Spring-Version" manifest attribute in > spring.jar/spring-beans.jar/spring-jdbc.jar/spring-context.jar, BTW. I'm not sure I agree here. Why bother keeping JARs versioned by CVS if they have a version number in the file name? You gain nothing but confusion IMHO. For example, as soon as the JAR moves around for whatever reason - ie deployed in an app in an app server - you suddenly have no idea what JAR it is. Very few people actually _use_ (or ever read ;)) the manifest files. If we can't version the JARs, can we at least have a README somewhere that lists exactly which version the JARs are? Or is that in the manifests? =20 > C) Is there really no explicit documentation on it? Funnily enough, noone= has > asked for it yet... The DTD is pretty self-explanatory and enriched with > comments, so it can serve as transitional documentation, I guess. OK cool - didn't know there was a DTD - I'll try reading that first :) M > Juergen >=20 >=20 > ________________________________ >=20 > Von: spr...@li... im Auftrag von= Rod > Johnson > Gesendet: So 23.11.2003 10:16 > An: spr...@li... > Betreff: Re: [Springframework-developer] 1.0 M3 prepared >=20 >=20 >=20 > A) I'm inclined to agree. I don't think a few megs are significant. It al= so > makes it harder to work out real download numbers. >=20 > B) Tough question. While it is nice to know what version things are, in m= y > projects as an end user I tend to rely on CVS to manage versioning. E.g. = my > manifest classpath, constructed in the build script, might reference > aopalliance.jar and I would rely on source control to ensure that it was = the > correct version for my source. (Of course without EJB, a manifest classpa= th > isn't usually needed.) > Maybe we should survey what other projects do (or go Maven-friendly). >=20 > C) We probably do need a document. The DTD has some documentation in it. >=20 > Regards, > Rod >=20 > ----- Original Message ----- > From: "Mike Cannon-Brookes" <mi...@at...> > To: "Spring Developer" <spr...@li...> > Sent: Sunday, November 23, 2003 5:38 AM > Subject: Re: [Springframework-developer] 1.0 M3 prepared >=20 >=20 > Can I make some suggestions before the release? >=20 > A) ship all source with the release, including samples. I don't see why w= e > need multiple ZIPs? It just complicates things and will frustrate users > trying out spring IMHO. Noone really cares if it's 11MB do they? (apologi= es > if this is an old already discussed issue - I'm just not sure the reason = for > two JARs) >=20 > B) Can we please, please, please version the JARs shipped? Eg > aopalliance.jar is useless for people building apps, what version is it? > Managing dependencies explicitly is important - make it > aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS etc. >=20 > C) On a slightly related note, I couldn't find any docs (maybe I'm blind)= on > the exact syntax of the applicationContext.xml file? (ie how to set lists= , > booleans etc) >=20 > Cheers, > Mike >=20 > On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned the > words: >=20 >> +1 for including the sample source in the base download. It's good as a >> reference. I have updated the MVC step-by-step document to reflect the > need >> to >> download both zips. >>=20 >> Thomas >>=20 >> Quoting Colin Sampaleanu <col...@ex...>: >>=20 >>> j=FCrgen h=F6ller [werk3AT] wrote: >>>=20 >>>> FYI, I've already committed the renaming from ListableBeanFactoryImpl = to >>> DefaultListableBeanFactory. The web MVC exception stuff will follow >>> tomorrow. >>>>=20 >>>> I've also reworked the Tiles example, using >>> org.springframework.samples.tiles as package now, and auto-detecting th= e >>> Tiles DTD. The FileNameViewController has now moved to >>> org.springframework.web.servlet.mvc. And I've changed my mind: I do lik= e > 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... >>>>=20 >>>> 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 t= o > the >>> same location. The former contains dist, docs, lib/aop-alliance, >>> lib/jakarta-commons/commons-logging.jar, src, and the readmes, while th= e >>> latter contains samples and the additional libs necessary for building > and >>> running them. >>>>=20 >>>> 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. >>>>=20 >>>> Juergen >>>>=20 >>>>=20 >>> It probably makes sense to split things up this way. If somebody doesn'= t >>> care about the libs for the samples it's a drag to pull them down each >>> release. Maybe it would make sense though to still include _sources_ fo= r >>> the samples even with the first jar. Sample sources sometimes help you >>> figure stuff out that is not really related. I know that when I was >>> initially looking at Spring and figuring out Application Contexts, I >>> looked at all the contexts in all the samples, even if I had no interes= t >=20 >>> at that time in actually building those samples or using those parts of >>> Spring (like the MVC). >>>=20 >>> Colin >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=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 >>>=20 >>=20 >>=20 >>=20 >>=20 >>=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 >=20 >=20 >=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 >=20 >=20 >=20 >=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 >=20 >=20 >=20 >=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: Matthew E. P. <ma...@me...> - 2003-11-23 16:30:58
|
B) Although I am new to the list, I agree with Mike. Hibernate keeps =20= track of this by putting a file called VERSION in the lib directory. =20= While it requires people to be maintain this file, it seems to solve =20 everyone's issues. File are still named xxxx.jar without a date or =20 version number. People who want versions know where to get them. Cheers, matthew On Nov 23, 2003, at 5:40 AM, j=FCrgen h=F6ller [werk3AT] wrote: > A) OK, I've scrapped the distinction between main download and samples = =20 > for the time being. An 11 MB download isn't that large, after all. > > B) Same as Rod, personally - for that kind of jar management, version =20= > numbers are rather a nuisance, as you can't simply do a drop-in update = =20 > but have to do a remove plus an add. We include the actual Spring =20 > version number as "Spring-Version" manifest attribute in =20 > spring.jar/spring-beans.jar/spring-jdbc.jar/spring-context.jar, BTW. > > C) Is there really no explicit documentation on it? Funnily enough, =20= > noone has asked for it yet... The DTD is pretty self-explanatory and =20= > enriched with comments, so it can serve as transitional documentation, = =20 > I guess. > > Juergen > > > ________________________________ > > Von: spr...@li... im Auftrag =20= > von Rod Johnson > Gesendet: So 23.11.2003 10:16 > An: spr...@li... > Betreff: Re: [Springframework-developer] 1.0 M3 prepared > > > > A) I'm inclined to agree. I don't think a few megs are significant. It = =20 > also > makes it harder to work out real download numbers. > > B) Tough question. While it is nice to know what version things are, =20= > in my > projects as an end user I tend to rely on CVS to manage versioning. =20= > E.g. my > manifest classpath, constructed in the build script, might reference > aopalliance.jar and I would rely on source control to ensure that it =20= > was the > correct version for my source. (Of course without EJB, a manifest =20 > classpath > isn't usually needed.) > Maybe we should survey what other projects do (or go Maven-friendly). > > C) We probably do need a document. The DTD has some documentation in =20= > it. > > Regards, > Rod > > ----- Original Message ----- > From: "Mike Cannon-Brookes" <mi...@at...> > To: "Spring Developer" =20 > <spr...@li...> > Sent: Sunday, November 23, 2003 5:38 AM > Subject: Re: [Springframework-developer] 1.0 M3 prepared > > > Can I make some suggestions before the release? > > A) ship all source with the release, including samples. I don't see =20= > why we > need multiple ZIPs? It just complicates things and will frustrate = users > trying out spring IMHO. Noone really cares if it's 11MB do they? =20 > (apologies > if this is an old already discussed issue - I'm just not sure the =20 > reason for > two JARs) > > B) Can we please, please, please version the JARs shipped? Eg > aopalliance.jar is useless for people building apps, what version is =20= > it? > Managing dependencies explicitly is important - make it > aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS = etc. > > C) On a slightly related note, I couldn't find any docs (maybe I'm =20 > blind) on > the exact syntax of the applicationContext.xml file? (ie how to set =20= > lists, > booleans etc) > > Cheers, > Mike > > On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned =20= > the > words: > >> +1 for including the sample source in the base download. It's good =20= >> as a >> reference. I have updated the MVC step-by-step document to reflect =20= >> the > need >> to >> download both zips. >> >> Thomas >> >> Quoting Colin Sampaleanu <col...@ex...>: >> >>> j=FCrgen h=F6ller [werk3AT] wrote: >>> >>>> FYI, I've already committed the renaming from =20 >>>> 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 = =20 >>> the >>> Tiles DTD. The FileNameViewController has now moved to >>> org.springframework.web.servlet.mvc. And I've changed my mind: I do =20= >>> 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 =20= >>> 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 =20 >>> extraction to > the >>> same location. The former contains dist, docs, lib/aop-alliance, >>> lib/jakarta-commons/commons-logging.jar, src, and the readmes, while = =20 >>> the >>> latter contains samples and the additional libs necessary for =20 >>> building > and >>> running them. >>>> >>>> What do you think? Should I commit the changed build script and use = =20 >>>> it > for >>> the M3 release? I believe it would make sense to split the release =20= >>> into > those >>> two files, as 11 MB is already a bit large for a single = distribution. >>>> >>>> Juergen >>>> >>>> >>> It probably makes sense to split things up this way. If somebody =20 >>> doesn't >>> care about the libs for the samples it's a drag to pull them down =20= >>> each >>> release. Maybe it would make sense though to still include _sources_ = =20 >>> for >>> the samples even with the first jar. Sample sources sometimes help =20= >>> you >>> figure stuff out that is not really related. I know that when I was >>> initially looking at Spring and figuring out Application Contexts, I >>> looked at all the contexts in all the samples, even if I had no =20 >>> interest > >>> at that time in actually building those samples or using those parts = =20 >>> of >>> Spring (like the MVC). >>> >>> 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-=20 >>> developer >>> >> >> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: SF.net Giveback Program. >> Does SourceForge.net help you be more productive? Does it >> help you create better code? SHARE THE LOVE, and help us help >> YOU! Click Here: http://sourceforge.net/donate/ >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> = https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-11-23 12:37:31
|
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. =20 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. =20 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. =20 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. =20 Juergen =20 ________________________________ 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 |
|
From: <jue...@we...> - 2003-11-23 19:38:21
|
Trevor, =20 Okidoki, so people have actually overridden the former userObject = method... I'll re-add it as deprecated for M3, delegating to the = getCommand method, to allow for catching it with the compiler. Thanks = for reporting this *before* the actual M3 release! =20 I guess migration from deprecated methods to their replacements should = be easy enough if people try M3 before any upcoming RC. Remove all = invocations of deprecated methods in M3, then go on to RC1, and you'll = be done :-) I don't think that we need an M4 just for that reason. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Trevor Cook Gesendet: So 23.11.2003 20:14 An: spr...@li... Betreff: RE: [Springframework-developer] 1.0 M3 prepared I've updated our projects to M3, and everything is working properly now. I did have a slight problem with a few places where I overrided = userObject (in the SimpleFormController) but no compilation errors were reported = (this took a while to track down). While the public api won't be frozen until = the RC, can I request that any changes to the public apis (method name = changes and parameter signatures) are done using the @deprecated tag, and the deprecated method simply calls the new method. This will ensure that = the compiler will report problems rather than things compiling ok and = failing properly. I know Juergen has been doing this with many recent changes, = but an "across-the-board" policy would make things easier now that the size = of Spring's code and my own has grown so large. These deprecations can be removed for the RC (possibly by creating an M4 first with deprecations = still in, and then an RC immediately with the deprecations removed for the = "final" public api). +1 to including source but no libs with samples Trevor -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: November 22, 2003 7:45 PM To: spr...@li... Subject: 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: Colin S. <col...@ex...> - 2003-11-23 20:37:06
|
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: Trevor C. <pr...@se...> - 2003-11-23 22:07:24
|
Yup, I'm one of the "special" people who override what you'd least expect= :) The suggestion for an M4 is only if we deprecate any methods between M3 a= nd RC1 (which could happen). Since it wouldn't de deprecated in M3, and I'm assuming we want all deprecations removed before RC1, any signature chang= es in the next month (approx) would need to be accounted for. If not new deprecations are added, I agree that an M4 isn't required, but that would indicate a public api freeze based on M3 (which I don't think we're doing= ). Trevor -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: November 23, 2003 2:36 PM To: spr...@li... Subject: Re: [Springframework-developer] 1.0 M3 prepared Trevor, Okidoki, so people have actually overridden the former userObject method.= .. I'll re-add it as deprecated for M3, delegating to the getCommand method,= to allow for catching it with the compiler. Thanks for reporting this *befor= e* the actual M3 release! I guess migration from deprecated methods to their replacements should be easy enough if people try M3 before any upcoming RC. Remove all invocatio= ns of deprecated methods in M3, then go on to RC1, and you'll be done :-) I don't think that we need an M4 just for that reason. Juergen ________________________________ Von: spr...@li... im Auftrag von Trevor Cook Gesendet: So 23.11.2003 20:14 An: spr...@li... Betreff: RE: [Springframework-developer] 1.0 M3 prepared I've updated our projects to M3, and everything is working properly now. I did have a slight problem with a few places where I overrided userObjec= t (in the SimpleFormController) but no compilation errors were reported (th= is took a while to track down). While the public api won't be frozen until = the RC, can I request that any changes to the public apis (method name change= s and parameter signatures) are done using the @deprecated tag, and the deprecated method simply calls the new method. This will ensure that the compiler will report problems rather than things compiling ok and failing properly. I know Juergen has been doing this with many recent changes, b= ut an "across-the-board" policy would make things easier now that the size o= f Spring's code and my own has grown so large. These deprecations can be removed for the RC (possibly by creating an M4 first with deprecations st= ill in, and then an RC immediately with the deprecations removed for the "fin= al" public api). +1 to including source but no libs with samples Trevor -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: November 22, 2003 7:45 PM To: spr...@li... Subject: 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-bo= x 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 an= d running them. What do you think? Should I commit the changed build script and use it fo= r 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 distributio= n. 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 defau= lt 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 "DefaultListableBeanFactor= y"? 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 ------------------------------------------------------- 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: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 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: Colin S. <col...@ex...> - 2003-11-23 03:25:20
|
jürgen höller [werk3AT] wrote: >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 > > It probably makes sense to split things up this way. If somebody doesn't care about the libs for the samples it's a drag to pull them down each release. Maybe it would make sense though to still include _sources_ for the samples even with the first jar. Sample sources sometimes help you figure stuff out that is not really related. I know that when I was initially looking at Spring and figuring out Application Contexts, I looked at all the contexts in all the samples, even if I had no interest at that time in actually building those samples or using those parts of Spring (like the MVC). Colin |
|
From: <tri...@tr...> - 2003-11-23 04:05:45
|
+1 for including the sample source in the base download. It's good as a reference. I have updated the MVC step-by-step document to reflect the need to download both zips. Thomas Quoting Colin Sampaleanu <col...@ex...>: > jürgen höller [werk3AT] wrote: > > >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 > > > > > It probably makes sense to split things up this way. If somebody doesn't > care about the libs for the samples it's a drag to pull them down each > release. Maybe it would make sense though to still include _sources_ for > the samples even with the first jar. Sample sources sometimes help you > figure stuff out that is not really related. I know that when I was > initially looking at Spring and figuring out Application Contexts, I > looked at all the contexts in all the samples, even if I had no interest > at that time in actually building those samples or using those parts of > Spring (like the MVC). > > 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 > |
|
From: Mike Cannon-B. <mi...@at...> - 2003-11-23 05:39:02
|
Can I make some suggestions before the release? A) ship all source with the release, including samples. I don't see why we need multiple ZIPs? It just complicates things and will frustrate users trying out spring IMHO. Noone really cares if it's 11MB do they? (apologies if this is an old already discussed issue - I'm just not sure the reason fo= r two JARs) B) Can we please, please, please version the JARs shipped? Eg aopalliance.jar is useless for people building apps, what version is it? Managing dependencies explicitly is important - make it aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS etc. C) On a slightly related note, I couldn't find any docs (maybe I'm blind) o= n the exact syntax of the applicationContext.xml file? (ie how to set lists, booleans etc)=20 Cheers, Mike On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned the words: > +1 for including the sample source in the base download. It's good as a > reference. I have updated the MVC step-by-step document to reflect the n= eed > to > download both zips. >=20 > Thomas >=20 > Quoting Colin Sampaleanu <col...@ex...>: >=20 >> j=FCrgen h=F6ller [werk3AT] wrote: >>=20 >>> FYI, I've already committed the renaming from ListableBeanFactoryImpl t= o >> DefaultListableBeanFactory. The web MVC exception stuff will follow >> tomorrow. >>>=20 >>> 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-b= ox >> working example. It already annoys me having to copy those files in for >> testing, so consider a new user... >>>=20 >>> 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 a= nd >> running them. >>>=20 >>> 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. >>>=20 >>> Juergen >>> =20 >>>=20 >> It probably makes sense to split things up this way. If somebody doesn't >> care about the libs for the samples it's a drag to pull them down each >> release. Maybe it would make sense though to still include _sources_ for >> the samples even with the first jar. Sample sources sometimes help you >> figure stuff out that is not really related. I know that when I was >> initially looking at Spring and figuring out Application Contexts, I >> looked at all the contexts in all the samples, even if I had no interest >> at that time in actually building those samples or using those parts of >> Spring (like the MVC). >>=20 >> Colin >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=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 >>=20 >=20 >=20 >=20 >=20 >=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: Rod J. <rod...@in...> - 2003-11-23 09:18:47
|
A) I'm inclined to agree. I don't think a few megs are significant. It also makes it harder to work out real download numbers. B) Tough question. While it is nice to know what version things are, in my projects as an end user I tend to rely on CVS to manage versioning. E.g. my manifest classpath, constructed in the build script, might reference aopalliance.jar and I would rely on source control to ensure that it was the correct version for my source. (Of course without EJB, a manifest classpath isn't usually needed.) Maybe we should survey what other projects do (or go Maven-friendly). C) We probably do need a document. The DTD has some documentation in it. Regards, Rod ----- Original Message ----- From: "Mike Cannon-Brookes" <mi...@at...> To: "Spring Developer" <spr...@li...> Sent: Sunday, November 23, 2003 5:38 AM Subject: Re: [Springframework-developer] 1.0 M3 prepared Can I make some suggestions before the release? A) ship all source with the release, including samples. I don't see why we need multiple ZIPs? It just complicates things and will frustrate users trying out spring IMHO. Noone really cares if it's 11MB do they? (apologies if this is an old already discussed issue - I'm just not sure the reason for two JARs) B) Can we please, please, please version the JARs shipped? Eg aopalliance.jar is useless for people building apps, what version is it? Managing dependencies explicitly is important - make it aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS etc. C) On a slightly related note, I couldn't find any docs (maybe I'm blind) on the exact syntax of the applicationContext.xml file? (ie how to set lists, booleans etc) Cheers, Mike On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned the words: > +1 for including the sample source in the base download. It's good as a > reference. I have updated the MVC step-by-step document to reflect the need > to > download both zips. > > Thomas > > Quoting Colin Sampaleanu <col...@ex...>: > >> jürgen höller [werk3AT] wrote: >> >>> 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 >>> >>> >> It probably makes sense to split things up this way. If somebody doesn't >> care about the libs for the samples it's a drag to pull them down each >> release. Maybe it would make sense though to still include _sources_ for >> the samples even with the first jar. Sample sources sometimes help you >> figure stuff out that is not really related. I know that when I was >> initially looking at Spring and figuring out Application Contexts, I >> looked at all the contexts in all the samples, even if I had no interest >> at that time in actually building those samples or using those parts of >> Spring (like the MVC). >> >> 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: 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: Trevor C. <pr...@se...> - 2003-11-23 19:14:52
|
I've updated our projects to M3, and everything is working properly now. I did have a slight problem with a few places where I overrided userObjec= t (in the SimpleFormController) but no compilation errors were reported (th= is took a while to track down). While the public api won't be frozen until = the RC, can I request that any changes to the public apis (method name change= s and parameter signatures) are done using the @deprecated tag, and the deprecated method simply calls the new method. This will ensure that the compiler will report problems rather than things compiling ok and failing properly. I know Juergen has been doing this with many recent changes, b= ut an "across-the-board" policy would make things easier now that the size o= f Spring's code and my own has grown so large. These deprecations can be removed for the RC (possibly by creating an M4 first with deprecations st= ill in, and then an RC immediately with the deprecations removed for the "fin= al" public api). +1 to including source but no libs with samples Trevor -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: November 22, 2003 7:45 PM To: spr...@li... Subject: 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-bo= x 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 an= d running them. What do you think? Should I commit the changed build script and use it fo= r 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 distributio= n. 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 defau= lt 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 "DefaultListableBeanFactor= y"? 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 |
