RE: [Springframework-developer] interface21 Properties editor in BeanWrapperImpl

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

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