Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-04-09 17:23:44
|
Hi Bruno, Well, PropertiesEditor isn't in sun.beans.editors but in = com.interface21.beans.propertyeditors, so the rt.jar contents are fine. = I don't understand why = com.interface21.beans.propertyeditors.PropertiesEditor doesn't get = registered automatically in your case... It definitely does on my = installation (with a current Spring version). ----- Concerning the comparison to Struts: Being a co-founder of Spring, I'm = somewhat biased, of course... First of all, Spring has a much broader = scope than Struts. It addresses every tier - data access, services, and = web - in a reusable and flexible fashion. I particularly like its = modularity: You can choose to use Struts for the web tier but use a = Spring ApplicationContext for your services layer, for example - without = any hassle. Or just use Spring JDBC in a project, using whatever you = like for the rest of your infrastructure. Of course, Spring as a whole offers solutions for a lot of typical = infrastructure issues, focussing on but not being restricted to J2EE = environments. Recent developments include pluggable transaction = management and AOP support. Ease of use and separation of concerns are = central ideas, to allow for applications that consist of clearly = separated layers instead of being web-centric. This enables reuse not = only across various server applications with or without web layer but = also including standalone applications.=20 Struts, on the other hand, is "just" a web MVC framework, targetted at = web-centric applications. It doesn't address reusable business logic = services or data access objects at all. For example, compare the = validation support: Struts' is tied to ActionForms while Spring's isn't = tied to web classes at all. Generally, Struts' API has some major design = flaws that make it inflexible and not suitable for fine-grained reuse of = application logic. It provides a lot features for web apps, though, = especially in release 1.1. Spring's web support is worth mentioning on its own, of course, besides = the rest of Spring's infrastructure. It is built in a very flexible way, = allowing for writing on controllers on any level you choose, be it = Controller at the HttpServletRequest level, CommandController at the = populated command level, or FormController at the form handling level. = Even beyond that, you can customize mapping strategies, view resolution, = etc. This is very different to Struts that just offers one single level = of controller implementation, and no fine-grained customization hooks. BTW here at werk3AT, we are using Spring for 2 major projects, one of it = being written from scratch and based on Spring in the first place. The = latter project is currently in the business logic phase, using Spring = for context infrastructure and configuration (providing a unit test = environment with minimal effort), and Hibernate for O/R mapping. At the = moment, there isn't even a J2EE container involved, just a simple test = environment with mock JNDI and a mock JDBC DataSource! The project will = use Spring's web MVC support in the UI phase (beginning soon) - then we = will switch to a J2EE container seamlessly. Again, if you're interested, come and join a Spring mailing list! Regards, Juergen DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung part of werk3AT internetmedien oeg europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 jue...@we... www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG -----Original Message----- From: Bruno THOMAS [mailto:bt...@al...] Sent: Wednesday, April 09, 2003 6:20 PM To: j=FCrgen h=F6ller [werk3AT] Subject: Re: [Springframework-developer] interface21 Properties editor in BeanWrapperImpl Hello J=FCrgen, > All editors named XXXEditor in these packages get registered as = editors for=20 > XXX automatically, like PropertiesEditor for Properties. The naming=20 > convention cannot be applied to String arrays, thus the explicit=20 > StringArrayPropertyEditor registration. OK I see so I did miss something... > I don't understand why uncommenting the line made a difference in your = > situation. I use the web stuff a lot, and setting UrlHandlerMapping=20 > properties works nicely for me, without explicit PropertiesEditor > registration. Hmmm, maybe a classloader issue? In fact I was wondering if it wasn't a JRE issue : I've got an IBM 1.3.0 = J2RE, and I made a jar tvf of the rt.jar : 0 Wed Feb 07 07:03:44 CET 2001 sun/beans/ 0 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/ 1068 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/BoolEditor.class 898 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/ByteEditor.class 573 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/NumberEditor.class 5148 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/ColorEditor.class 546 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/DoubleEditor.class 884 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/FloatEditor.class 4886 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/FontEditor.class 542 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/IntEditor.class 880 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/LongEditor.class 903 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/ShortEditor.class 708 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/StringEditor.class 0 Wed Feb 07 07:03:44 CET 2001 sun/beans/infos/ 1468 Wed Feb 07 07:03:44 CET 2001 = sun/beans/infos/ComponentBeanInfo.class So there is no PropertiesEditor.class in the sun.beans.editors. Maybe in the static init of BeanWrapperImpl after the = setEditorSearchPath=20 there should be a workaround like: if (PropertyEditorManager.findEditor(Properties.class)=3D=3Dnull) { = PropertyEditorManager.registerEditor(Properties.class,PropertiesEditor.cl= ass) ; } What do you think ? BTW in comparison with struts what do you think of interface21 (or = Spring=20 now) ?? Regards, Bruno |
|
From: Srikanth S <sri...@co...> - 2003-04-10 07:13:47
|
This problem might occur depending on the security policy setting on the JVM on which your app server is running. If you making the appropriate JVM setting this problem will be solved. Hope this helps Srikanth S jürgen höller [werk3AT] wrote: >Hi Bruno, > >Well, PropertiesEditor isn't in sun.beans.editors but in com.interface21.beans.propertyeditors, so the rt.jar contents are fine. I don't understand why com.interface21.beans.propertyeditors.PropertiesEditor doesn't get registered automatically in your case... It definitely does on my installation (with a current Spring version). > >----- > >Concerning the comparison to Struts: Being a co-founder of Spring, I'm somewhat biased, of course... First of all, Spring has a much broader scope than Struts. It addresses every tier - data access, services, and web - in a reusable and flexible fashion. I particularly like its modularity: You can choose to use Struts for the web tier but use a Spring ApplicationContext for your services layer, for example - without any hassle. Or just use Spring JDBC in a project, using whatever you like for the rest of your infrastructure. > >Of course, Spring as a whole offers solutions for a lot of typical infrastructure issues, focussing on but not being restricted to J2EE environments. Recent developments include pluggable transaction management and AOP support. Ease of use and separation of concerns are central ideas, to allow for applications that consist of clearly separated layers instead of being web-centric. This enables reuse not only across various server applications with or without web layer but also including standalone applications. > >Struts, on the other hand, is "just" a web MVC framework, targetted at web-centric applications. It doesn't address reusable business logic services or data access objects at all. For example, compare the validation support: Struts' is tied to ActionForms while Spring's isn't tied to web classes at all. Generally, Struts' API has some major design flaws that make it inflexible and not suitable for fine-grained reuse of application logic. It provides a lot features for web apps, though, especially in release 1.1. > >Spring's web support is worth mentioning on its own, of course, besides the rest of Spring's infrastructure. It is built in a very flexible way, allowing for writing on controllers on any level you choose, be it Controller at the HttpServletRequest level, CommandController at the populated command level, or FormController at the form handling level. Even beyond that, you can customize mapping strategies, view resolution, etc. This is very different to Struts that just offers one single level of controller implementation, and no fine-grained customization hooks. > >BTW here at werk3AT, we are using Spring for 2 major projects, one of it being written from scratch and based on Spring in the first place. The latter project is currently in the business logic phase, using Spring for context infrastructure and configuration (providing a unit test environment with minimal effort), and Hibernate for O/R mapping. At the moment, there isn't even a J2EE container involved, just a simple test environment with mock JNDI and a mock JDBC DataSource! The project will use Spring's web MVC support in the UI phase (beginning soon) - then we will switch to a J2EE container seamlessly. > >Again, if you're interested, come and join a Spring mailing list! > >Regards, >Juergen > > >DI Jürgen Höller >Senior System Architect >______________________________________ > >werk3ATS - division systementwicklung >part of werk3AT internetmedien oeg > >europaplatz 4 >A - 4020 linz > >t. +43 (0) 732 71 65 29 502 >f. +43 (0) 732 71 65 29 3 >jue...@we... >www.werk3at.com >______________________________________ >werk3ATS - WIR ENTWICKELN ERFOLG > > >-----Original Message----- >From: Bruno THOMAS [mailto:bt...@al...] >Sent: Wednesday, April 09, 2003 6:20 PM >To: jürgen höller [werk3AT] >Subject: Re: [Springframework-developer] interface21 Properties editor >in BeanWrapperImpl > > >Hello Jürgen, > > > >>All editors named XXXEditor in these packages get registered as editors for >>XXX automatically, like PropertiesEditor for Properties. The naming >>convention cannot be applied to String arrays, thus the explicit >>StringArrayPropertyEditor registration. >> >> > >OK I see so I did miss something... > > > >>I don't understand why uncommenting the line made a difference in your >>situation. I use the web stuff a lot, and setting UrlHandlerMapping >>properties works nicely for me, without explicit PropertiesEditor >>registration. Hmmm, maybe a classloader issue? >> >> > >In fact I was wondering if it wasn't a JRE issue : I've got an IBM 1.3.0 >J2RE, and I made a jar tvf of the rt.jar : > >0 Wed Feb 07 07:03:44 CET 2001 sun/beans/ >0 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/ >1068 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/BoolEditor.class >898 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/ByteEditor.class >573 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/NumberEditor.class >5148 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/ColorEditor.class >546 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/DoubleEditor.class >884 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/FloatEditor.class >4886 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/FontEditor.class >542 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/IntEditor.class >880 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/LongEditor.class >903 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/ShortEditor.class >708 Wed Feb 07 07:03:44 CET 2001 sun/beans/editors/StringEditor.class >0 Wed Feb 07 07:03:44 CET 2001 sun/beans/infos/ >1468 Wed Feb 07 07:03:44 CET 2001 sun/beans/infos/ComponentBeanInfo.class > >So there is no PropertiesEditor.class in the sun.beans.editors. > >Maybe in the static init of BeanWrapperImpl after the setEditorSearchPath >there should be a workaround like: > >if (PropertyEditorManager.findEditor(Properties.class)==null) { > PropertyEditorManager.registerEditor(Properties.class,PropertiesEditor.class) >; >} > >What do you think ? > >BTW in comparison with struts what do you think of interface21 (or Spring >now) ?? > >Regards, > >Bruno > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger >for complex code. Debugging C/C++ programs can leave you feeling lost and >disoriented. TotalView can help you find your way. Available on major UNIX >and Linux platforms. Try it free. www.etnus.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |
