Menu
▾
▴
Re: [Springframework-developer] 1.0 M3 prepared
|
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 |
