springframework-developer — Spring Framework developers list

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

[Srikanth S <sri...@co...>]

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
>
>
>  
>

RE: [Springframework-developer] Spring vs Struts (was: interface2 1 Properties editor in BeanWrapperImpl)

[John C. <joh...@sa...>]

I think I may have come across the wrong way. I didn't mean to imply
anything about Struts being better then Spring or vice versa. Quite the
contrary. I've been using Spring since I've read Rod's book (before it
became spring) and I've been using it in one of my projects as a =
learning
endeavor. I also use Struts both at work at in "playing around" with my =
own
stuff. I completely agree with what you said previously about Struts =
and
Spring and what you just said as well. My idea is to use Spring in the
business and middle tier and either Spring again in the front end or =
Struts,
I haven't decided yet. Struts is JUST MVC that's all. Spring is much =
more.
Now that's out of the way...

What I wanted to see an example of, was how to do reusable validation =
logic
on business components in Spring in a way that is totally separate from =
the
MVC framework one ends up using. The examples in Rod's book are ok, =
but,
well without offending Rod, somewhat simple in detail and =
implementation. A
more realistic scenario is probably what I am looking for.

Regards,
John

> -----Original Message-----
> From: j=FCrgen h=F6ller [werk3AT] =
[mailto:jue...@we...]
> Sent: Wednesday, April 09, 2003 1:56 PM
> To: spr...@li...
> Subject: [Springframework-developer] Spring vs Struts (was: =
interface21
> Properties editor in BeanWrapperImpl)
>=20
> Hi John,
>=20
> What exactly would you like to see an example for? Reusable business =
logic
> services via Spring? Validation not tied to web classes? For a start, =
the
> box office demo application coming with Rod's book shows both. =
Indeed, we
> need lots of additional documentation and best practices guides... =
but
> currently we're still busy implementing and refining ;-)
>=20
> I didn't mean to imply that Struts would not allow for reusable =
business
> logic at all. It just doesn't support it in any way, so you have to =
find
> or build a suitable infrastructure yourself. Therefore, many Struts
> applications just separate at the web MVC level: Business logic ends =
up in
> web controllers but not in dedicated business logic services. That's =
where
> using Spring as middle tier framework for Struts web apps makes =
sense.
>=20
> Of course, Struts shares this particular limitation with other web =
MVC
> frameworks like WebWork. This isn't meant as offence, such =
infrastructure
> is simply beyond their scope.
>=20
> Regards,
> Juergen
>=20
>=20
> -----Original Message-----
> From: John Cavacas [mailto:joh...@sa...]
> Sent: Wednesday, April 09, 2003 7:30 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] interface21 Properties =
editor
> in BeanWrapperImpl
>=20
>=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.
>=20
> [John Cavacas]
>=20
> I would love to see an example and explanation of this. Maybe I'm =
just
> thick
> headed but I just don't get it. I'm sure others would too.
>=20
> Thanks,
> John
>=20
>=20
>=20
>=20
> This communication is intended for the use of the individual(s) or =
entity
> it
> was addressed to and may contain confidential and/or privileged
> information.
> If the reader of this transmission is not the intended recipient, you =
are
> hereby notified that any review, dissemination, distribution or =
copying of
> this communication is prohibited.  If you receive this communication =
in
> error, please notify the sender immediately and delete this =
communication
> from your system(s) to which it was sent and/or replicated to. (c) =
2002
> Sapiens Americas Corp.
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
> -------------------------------------------------------
> 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



This communication is intended for the use of the individual(s) or =
entity it
was addressed to and may contain confidential and/or privileged =
information.
If the reader of this transmission is not the intended recipient, you =
are
hereby notified that any review, dissemination, distribution or copying =
of
this communication is prohibited.  If you receive this communication in
error, please notify the sender immediately and delete this =
communication
from your system(s) to which it was sent and/or replicated to. =A9 2002
Sapiens Americas Corp.

[Springframework-developer] Spring vs Struts (was: interface21 Properties editor in BeanWrapperImpl)

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

Hi John,

What exactly would you like to see an example for? Reusable business =
logic services via Spring? Validation not tied to web classes? For a =
start, the box office demo application coming with Rod's book shows =
both. Indeed, we need lots of additional documentation and best =
practices guides... but currently we're still busy implementing and =
refining ;-)

I didn't mean to imply that Struts would not allow for reusable business =
logic at all. It just doesn't support it in any way, so you have to find =
or build a suitable infrastructure yourself. Therefore, many Struts =
applications just separate at the web MVC level: Business logic ends up =
in web controllers but not in dedicated business logic services. That's =
where using Spring as middle tier framework for Struts web apps makes =
sense.

Of course, Struts shares this particular limitation with other web MVC =
frameworks like WebWork. This isn't meant as offence, such =
infrastructure is simply beyond their scope.

Regards,
Juergen


-----Original Message-----
From: John Cavacas [mailto:joh...@sa...]
Sent: Wednesday, April 09, 2003 7:30 PM
To: spr...@li...
Subject: RE: [Springframework-developer] interface21 Properties editor
in BeanWrapperImpl


> 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.=20

[John Cavacas]=20

I would love to see an example and explanation of this. Maybe I'm just =
thick
headed but I just don't get it. I'm sure others would too.

Thanks,
John
=20



This communication is intended for the use of the individual(s) or =
entity it
was addressed to and may contain confidential and/or privileged =
information.
If the reader of this transmission is not the intended recipient, you =
are
hereby notified that any review, dissemination, distribution or copying =
of
this communication is prohibited.  If you receive this communication in
error, please notify the sender immediately and delete this =
communication
from your system(s) to which it was sent and/or replicated to. (c) 2002
Sapiens Americas Corp.


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The =
debugger=20
for complex code. Debugging C/C++ programs can leave you feeling lost =
and=20
disoriented. TotalView can help you find your way. Available on major =
UNIX=20
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

[John C. <joh...@sa...>]

> 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. 

[John Cavacas] 

I would love to see an example and explanation of this. Maybe I'm just thick
headed but I just don't get it. I'm sure others would too.

Thanks,
John
 



This communication is intended for the use of the individual(s) or entity it
was addressed to and may contain confidential and/or privileged information.
If the reader of this transmission is not the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying of
this communication is prohibited.  If you receive this communication in
error, please notify the sender immediately and delete this communication
from your system(s) to which it was sent and/or replicated to. (c) 2002
Sapiens Americas Corp.

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

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

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

Hi Bruno,

The line registering PropertiesEditor isn't necessary because the same =
static initializer code that you cited contains the following:

	// Register all editors in our standard package
	PropertyEditorManager.setEditorSearchPath(new String[] {
		"sun.beans.editors",
		"com.interface21.beans.propertyeditors"
	});

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.

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?

Anyway, let me invite you to join one of our mailing lists. The project =
is now hosted at SourceForge and is called "Spring Framework":

	http://sourceforge.net/projects/springframework

You could try to download a current version of the framework and recheck =
the property editor issue for your application. Unfortunately, our first =
official release 0.8 isn't out yet, so you'll need to get the stuff from =
the SourceForge CVS. FYI, 0.8 should get released in April, and 1.0 =
around end of May.

Note that the i21-web-demo accompanying the book will probably not work =
on a current Spring version without slight modifications. There have =
been major new framework features since the book version, introducing =
some incompatibilities for the sake of clearness (like new subpackages, =
renamed classes and methods, etc). AFAIK, Rod has already tried to adapt =
the demo, but it isn't in CVS yet.

Regards,
Juergen


-----Original Message-----
From: Bruno THOMAS [mailto:bt...@al...]=20
Sent: Wednesday, April 09, 2003 10:27 AM
To: ExpertJ2EE with RodJohnson
Subject: [expertj2ee_with_rodjohnson] interface21 Properties editor in
BeanWrapperImpl


Hi all,


When I deployed the i21-web-demo.war I had always an=20
ErrorCodedPropertyVetoException: errorCode=3D[typeMismatch]; =
message=3D(Failed
to=20
convert property value of type [java.lang.String] to required type=20
[java.util.Properties]

Anyway, I didn't have time to get to see what was happening, so I =
decided to

make a little demo using interface21 with a piece of webapp that I want =
to=20
migrate from struts to interface21. I've had the same exception.

After getting source with CVS and few moments in the code, I've been =
able to

see that in init of BeanWrapperImpl the line 57 :

PropertyEditorManager.registerEditor(Properties.class,PropertiesEditor.cl=
ass
);

was commented out. As the PropertiesEditor is necessary for listing of =
url=20
with the UrlHandlerMapping, I've removed the comment. After registering=20
PropertiesEditor, all worked well (the web-demo and my demo).

So why it was commented out ? Did I missed something (with for example=20
StringArrayPropertyEditor) ?

Is anybody having a clue about this ?=20
Thanks by advance.

Bruno THOMAS

PS : sorry for my poor english

---
Change your mail options at http://p2p.wrox.com/manager.asp or=20
to unsubscribe send a blank email to
lea...@p2.....


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The =
debugger=20
for complex code. Debugging C/C++ programs can leave you feeling lost =
and=20
disoriented. TotalView can help you find your way. Available on major =
UNIX=20
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] FW: [expertj2ee_with_rodjohnson] interface21 Properties editor in BeanWrapperImpl

[Kopylenko, D. <dko...@ac...>]

-----Original Message-----
From: Bruno THOMAS [mailto:bt...@al...] 
Sent: Wednesday, April 09, 2003 10:27 AM
To: ExpertJ2EE with RodJohnson
Subject: [expertj2ee_with_rodjohnson] interface21 Properties editor in
BeanWrapperImpl


Hi all,


When I deployed the i21-web-demo.war I had always an 
ErrorCodedPropertyVetoException: errorCode=[typeMismatch]; message=(Failed
to 
convert property value of type [java.lang.String] to required type 
[java.util.Properties]

Anyway, I didn't have time to get to see what was happening, so I decided to

make a little demo using interface21 with a piece of webapp that I want to 
migrate from struts to interface21. I've had the same exception.

After getting source with CVS and few moments in the code, I've been able to

see that in init of BeanWrapperImpl the line 57 :

PropertyEditorManager.registerEditor(Properties.class,PropertiesEditor.class
);

was commented out. As the PropertiesEditor is necessary for listing of url 
with the UrlHandlerMapping, I've removed the comment. After registering 
PropertiesEditor, all worked well (the web-demo and my demo).

So why it was commented out ? Did I missed something (with for example 
StringArrayPropertyEditor) ?

Is anybody having a clue about this ? 
Thanks by advance.

Bruno THOMAS

PS : sorry for my poor english

---
Change your mail options at http://p2p.wrox.com/manager.asp or 
to unsubscribe send a blank email to
lea...@p2.....

[Springframework-developer] javadocs

[Isabelle M. <met...@pa...>]

Hi everyone,

I've fixed all I could. There is one error left in ResultReader which I cannot figure out, plus a bunch that refer to a class Interceptor which simply isn't there.

A few hints for the future :
(1) in an @see tag, never put anything after the closing <.a>. In other words, the following is a no-n0 :

@see <a href="blabla">Blabla<.a> for more detail.

Isabelle

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

Re: [Springframework-developer] javadocs

[Tony F. <ton...@ya...>]

Not a problem, I know it's not a pressing issue.  I looked at the build.properties again last night and we have a property set for the version # already (it's used at least for creating the JAR file name).  Thus the version # within JavaDocs should be handled correctly with Jalopy as well.
FYI - I modified the build.xml file so it now contains descriptions for all "public" targets.  They will now show up with "ant -projecthelp"
 
 Rod Johnson <rod...@in...> wrote:Tony,

I did mean to look at it tonight, but I spent longer on AOP than I expected.

I'm still keen and hopefully will get to it on the weekend.

Regards,
Rod

----- Original Message -----
From: "Tony Falabella" 
To: ;

Sent: Monday, April 07, 2003 7:21 PM
Subject: Re: [Springframework-developer] javadocs


>
> Rod,
> If we decide to use Jalopy and turn on the "JavaDocs" feature of it (which
still has a few quirks right now but will be fixed with the next release)
items #2 and #3 will be detected when the Ant script is run. As far as the
@version one, this would only be automatically put into the Javadocs if we
set this in the build.properties file (and then we'd have to make sure to
update that attribute within the property file whenever a new release
version was done).
> Have you had a chance to look over the proposed issues I sent in regards
to Jalopy?
>
> Isabelle Muszynski wrote:Hi everyone,
>
> I've started fixing the javadocs and there are 3 recurring problems :
>
> (1) an @version tag without version number
> (2) a package.html file that doesn't contain the proper html tags. Should
be like this :
>
>
>
>
> blabla
>
>
>
> (3) tags where the href is not enclosed in quotes. Should be like this :
>
>
> Please try to avoid these errors in the future, fixing javadocs really
isn't any fun.
>
> Isabelle
>
> --
> Isabelle Muszynski
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] javadocs

[Rod J. <rod...@in...>]

Tony,

I did mean to look at it tonight, but I spent longer on AOP than I expected.

I'm still keen and hopefully will get to it on the weekend.

Regards,
Rod

----- Original Message -----
From: "Tony Falabella" <ton...@ya...>
To: <met...@pa...>;
<spr...@li...>
Sent: Monday, April 07, 2003 7:21 PM
Subject: Re: [Springframework-developer] javadocs


>
> Rod,
> If we decide to use Jalopy and turn on the "JavaDocs" feature of it (which
still has a few quirks right now but will be fixed with the next release)
items #2 and #3 will be detected when the Ant script is run.  As far as the
@version one, this would only be automatically put into the Javadocs if we
set this in the build.properties file (and then we'd have to make sure to
update that attribute within the property file whenever a new release
version was done).
> Have you had a chance to look over the proposed issues I sent in regards
to Jalopy?
>
>  Isabelle Muszynski <met...@pa...> wrote:Hi everyone,
>
> I've started fixing the javadocs and there are 3 recurring problems :
>
> (1) an @version tag without version number
> (2) a package.html file that doesn't contain the proper html tags. Should
be like this :
>
>
>
>
> blabla
>
>
>
> (3) tags where the href is not enclosed in quotes. Should be like this :
>
>
> Please try to avoid these errors in the future, fixing javadocs really
isn't any fun.
>
> Isabelle
>
> --
> Isabelle Muszynski
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] aopalliance

[Rod J. <rod...@in...>]

It's not published yet. It's a project to coordinate APIs between Nanning,
Spring and jAdvise to allow for portability of AOP interceptors.

We should be setting up a web site and Sourceforge CVS (aopalliance project
already set up) but I don't have a date yet.

Rod

----- Original Message -----
From: "Isabelle Muszynski" <met...@pa...>
To: <spr...@li...>
Sent: Tuesday, April 08, 2003 12:24 PM
Subject: [Springframework-developer] aopalliance


> Could someone give me the url for the aopalliance stuff, I can't find it
and need it for fixing the javadocs.
>
> Thanks,
>
> Isabelle
>
>
> --
> Isabelle Muszynski
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] aopalliance

[Isabelle M. <met...@pa...>]

Could someone give me the url for the aopalliance stuff, I can't find it and need it for fixing the javadocs.

Thanks,

Isabelle


-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

Fw: [Springframework-developer] Ordering HandlerMappings and other beans

[Rod J. <rod...@in...>]

reply to again

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "jürgen höller [werk3AT]" <jue...@we...>
Sent: Monday, April 07, 2003 8:51 PM
Subject: Re: [Springframework-developer] Ordering HandlerMappings and other
beans


> Agreed to all. I like the ordered idea and may use it to solve an AOP
> problem I'm working on. All ordered go before all unordered, I presume.
>
> I haven't seen your separator suggestion, but I don't mind changes to
> BeanNameUrlHandler, which is a bit basic anyway.
>
> Rod
>
> ----- Original Message -----
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: "Rod Johnson" <rod...@in...>
> Sent: Monday, April 07, 2003 8:42 PM
> Subject: Re: [Springframework-developer] Ordering HandlerMappings and
other
> beans
>
>
> > You're right, of course - BeanNameUrlHandlerMapping is the default, so
> SimpleUrlHandlerMapping makes more sense.
> >
> > I assume you agree not only to the naming issue, but to the ordering
issue
> and the BeanNameUrlHandlerMapping separator change too? ;-)
> >
> > Juergen
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Rod Johnson [mailto:rod...@in...]
> > Gesendet: Mo 07.04.2003 20:52
> > An: jürgen höller [werk3AT];
> spr...@li...
> > Cc:
> > Betreff: Re: [Springframework-developer] Ordering HandlerMappings and
> other beans
> >
> >
> >
> > Agreed. What about SimpleUrlHandlerMapping, as it's not the default?
> >
> > ----- Original Message -----
> > From: "jürgen höller [werk3AT]" <jue...@we...>
> > To: <spr...@li...>
> > Sent: Monday, April 07, 2003 5:14 PM
> > Subject: RE: [Springframework-developer] Ordering HandlerMappings and
> other
> > beans
> >
> >
> > A naming issue: UrlHandlerMapping should probably be called
> > DefaultUrlHanderMapping or some other more meaningful name. Especially
> with
> > AbstractUrlHandlerMapping in addition to BeanNameUrlHandlerMapping,
naming
> a
> > concrete implementation UrlHandlerMapping seems inappropriate.
> >
> > Of course, this would mean a name change that affects ControllerServlet
> > context config files. But I think that we should prefer proper names and
> > proper structure to backward compatibility, at least as long as there
> isn't
> > an official release.
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: jürgen höller [werk3AT]
> > Sent: Monday, April 07, 2003 5:09 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] Ordering HandlerMappings and other
> > beans
> >
> >
> > Hi Rod, everyone,
> >
> > I've just developed a custom HandlerMapping strategy for one of our
> > applications and faced the issue that I wanted to retrieve beans of a
> > certain class from the ApplicationContext in a specifyable order.
Looking
> > for a solution, I've recognized that exactly the same issue occurs with
> > HandlerMappings themselves too. Currently, ControllerServlet solves this
> via
> > sorting by bean name ("a.urlMap", "b.urlMap"), but frankly, I've never
> > particularly liked that solution.
> >
> > So I've applied a new approach to both HandlerMapping order and the
> problem
> > in the custom application. Details of the HandlerMapping solution
follow:
> >
> > - I've introduced a Ordered interface to com.interface21.core, featuring
> one
> > single method "int getOrder()", and an associated OrderComparator. The
> > getOrder() method simply returns an int value, higher value meaning
> greater
> > in terms of sorting resp. lower priority. This is somewhat analogous to
> > Servlet load-on-startup values. OrderComparator sorts by order value,
> > treating non-Ordered objects as greatest resp. lowest priority.
> >
> > - ControllerServlet now sorts HandlerMappings (and HandlerAdapters, for
> > consistency's sake) by sorting them with OrderComparator, rather than by
> > bean name. Non-Ordered instances are thus applied in an arbitrary order,
> but
> > instances can choose to implement Ordered to be able to specify a higher
> > priority. Of course, the obvious way is adding an "order" bean property
> with
> > getter and setter, to allow specifying the order value in the
> > ApplicationContext configuration.
> >
> > - There's AbstractUrlHandlerMapping now, an abstract base class for
> > url-based HandlerMapping implementations. In addition to refactored
things
> > like unified handler initialization code (propagating ApplicationContext
> and
> > LocaleResolver) for both BeanNameUrlHandlerMapping and
UrlHandlerMapping,
> it
> > offers a property-based Ordered implementation.
> >
> > An example snippet from an applicationContext.xml file:
> >
> > <bean name="myUrlMap"
> > class="com.interface21.web.servlet.handler.UrlHandlerMapping">
> > <property name="order">0</property>
> > <property name="mappings">
> > /example.do=exampleController
> > </property>
> > </bean>
> >
> > <bean name="yourUrlMap"
> > class="com.interface21.web.servlet.handler.UrlHandlerMapping">
> > <property name="order">1</property>
> > <property name="mappings">
> > /example.do=/exampleFormController
> > /exampleForm.do=exampleFormController
> > </property>
> > </bean>
> >
> > According to the order values, myUrlMap gets applied first, thus
> > "/example.do" will lead to exampleController's execution. If one sets
> > myUrlMap's order value to "2" or omits its order line, yourUrlMap will
get
> > applied first, thus "/example.do" will lead to exampleFormController's
> > execution.
> >
> > I consider this more elegant and more flexible than sorting by bean
name.
> > After all, servlets don't get started in the order of their name for a
> > reason... ;-) Fortunately, an application developer doesn't have to care
> > about the Ordered interface if he doesn't want to: A single
HandlerMapping
> > definition doesn't need to specify an order value, and a HandlerMapping
> > implementation doesn't need to implement Ordered.
> >
> > If noone objects, I will check in the changes promptly, as they go hand
in
> > hand with other things like the UrlHandlerMapping refactoring and some
> > ControllerServlet polishing.
> >
> > 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
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ValueWeb:
> > Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> > No other company gives more support or power for your dedicated server
> > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ValueWeb:
> > Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> > No other company gives more support or power for your dedicated server
> > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> >
>

Re: [Springframework-developer] Ordering HandlerMappings and other beans

[Rod J. <rod...@in...>]

Agreed. What about SimpleUrlHandlerMapping, as it's not the default?

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Monday, April 07, 2003 5:14 PM
Subject: RE: [Springframework-developer] Ordering HandlerMappings and other
beans


A naming issue: UrlHandlerMapping should probably be called
DefaultUrlHanderMapping or some other more meaningful name. Especially with
AbstractUrlHandlerMapping in addition to BeanNameUrlHandlerMapping, naming a
concrete implementation UrlHandlerMapping seems inappropriate.

Of course, this would mean a name change that affects ControllerServlet
context config files. But I think that we should prefer proper names and
proper structure to backward compatibility, at least as long as there isn't
an official release.

Juergen


-----Original Message-----
From: jürgen höller [werk3AT]
Sent: Monday, April 07, 2003 5:09 PM
To: spr...@li...
Subject: [Springframework-developer] Ordering HandlerMappings and other
beans


Hi Rod, everyone,

I've just developed a custom HandlerMapping strategy for one of our
applications and faced the issue that I wanted to retrieve beans of a
certain class from the ApplicationContext in a specifyable order. Looking
for a solution, I've recognized that exactly the same issue occurs with
HandlerMappings themselves too. Currently, ControllerServlet solves this via
sorting by bean name ("a.urlMap", "b.urlMap"), but frankly, I've never
particularly liked that solution.

So I've applied a new approach to both HandlerMapping order and the problem
in the custom application. Details of the HandlerMapping solution follow:

- I've introduced a Ordered interface to com.interface21.core, featuring one
single method "int getOrder()", and an associated OrderComparator. The
getOrder() method simply returns an int value, higher value meaning greater
in terms of sorting resp. lower priority. This is somewhat analogous to
Servlet load-on-startup values. OrderComparator sorts by order value,
treating non-Ordered objects as greatest resp. lowest priority.

- ControllerServlet now sorts HandlerMappings (and HandlerAdapters, for
consistency's sake) by sorting them with OrderComparator, rather than by
bean name. Non-Ordered instances are thus applied in an arbitrary order, but
instances can choose to implement Ordered to be able to specify a higher
priority. Of course, the obvious way is adding an "order" bean property with
getter and setter, to allow specifying the order value in the
ApplicationContext configuration.

- There's AbstractUrlHandlerMapping now, an abstract base class for
url-based HandlerMapping implementations. In addition to refactored things
like unified handler initialization code (propagating ApplicationContext and
LocaleResolver) for both BeanNameUrlHandlerMapping and UrlHandlerMapping, it
offers a property-based Ordered implementation.

An example snippet from an applicationContext.xml file:

<bean name="myUrlMap"
class="com.interface21.web.servlet.handler.UrlHandlerMapping">
<property name="order">0</property>
<property name="mappings">
/example.do=exampleController
</property>
</bean>

<bean name="yourUrlMap"
class="com.interface21.web.servlet.handler.UrlHandlerMapping">
<property name="order">1</property>
<property name="mappings">
/example.do=/exampleFormController
/exampleForm.do=exampleFormController
</property>
</bean>

According to the order values, myUrlMap gets applied first, thus
"/example.do" will lead to exampleController's execution. If one sets
myUrlMap's order value to "2" or omits its order line, yourUrlMap will get
applied first, thus "/example.do" will lead to exampleFormController's
execution.

I consider this more elegant and more flexible than sorting by bean name.
After all, servlets don't get started in the order of their name for a
reason... ;-) Fortunately, an application developer doesn't have to care
about the Ordered interface if he doesn't want to: A single HandlerMapping
definition doesn't need to specify an order value, and a HandlerMapping
implementation doesn't need to implement Ordered.

If noone objects, I will check in the changes promptly, as they go hand in
hand with other things like the UrlHandlerMapping refactoring and some
ControllerServlet polishing.

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



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] javadocs

[Tony F. <ton...@ya...>]

Rod,
If we decide to use Jalopy and turn on the "JavaDocs" feature of it (which still has a few quirks right now but will be fixed with the next release) items #2 and #3 will be detected when the Ant script is run.  As far as the @version one, this would only be automatically put into the Javadocs if we set this in the build.properties file (and then we'd have to make sure to update that attribute within the property file whenever a new release version was done).
Have you had a chance to look over the proposed issues I sent in regards to Jalopy?
 
 Isabelle Muszynski <met...@pa...> wrote:Hi everyone,

I've started fixing the javadocs and there are 3 recurring problems :

(1) an @version tag without version number
(2) a package.html file that doesn't contain the proper html tags. Should be like this :




blabla



(3) tags where the href is not enclosed in quotes. Should be like this :


Please try to avoid these errors in the future, fixing javadocs really isn't any fun.

Isabelle

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] StringUtils needs InternalErrorException

[Isabelle M. <met...@pa...>]

Hi Juergen,

Actually cvs works quite well, but it has some quirks. I should have done a checkout having the add to make sure everything was fine. Mea culpa. I had some problems when trying to add, at first it complained about insufficient privileges.

Isabelle

On Mon, Apr 07, 2003 at 06:04:10PM +0200, jürgen höller [werk3AT] wrote:
> I've checked in the file you've just sent me. Everything should compile now. I guess that CVS isn't the most reliable piece of software in the world... ;-)
> 
> Juergen
> 
> 
> -----Original Message-----
> From: Isabelle Muszynski [mailto:met...@pa...]
> Sent: Monday, April 07, 2003 5:45 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] StringUtils needs
> InternalErrorException
> 
> 
> Very bizarre, as I did an add of InternalErrorException, followed by a commit. I'm at work now, so don't have the time to figure out what went wrong. However, let me try to retrieve the missing file from my home pc and then I'll email it to you, and maybe you can do the add.
> 
> Isabelle
> 
> 
> On Mon, Apr 07, 2003 at 05:15:04PM +0200, jürgen höller [werk3AT] wrote:
> > Isabelle,
> > 
> > The version of StringUtils that you've checked in depends on a new InternalErrorException in the core package. But the latter isn't in CVS yet...
> > 
> > Regards,
> > Juergen
> > 
> > P.S.:
> > I've just seen that someone has already posted a SourceForge bug report for this.
> > 
> > 
> > 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
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ValueWeb:
> > Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> > No other company gives more support or power for your dedicated server
> > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > 
> > 
> 
> -- 
> Isabelle Muszynski
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

RE: [Springframework-developer] Ordering HandlerMappings and other beans

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

A naming issue: UrlHandlerMapping should probably be called =
DefaultUrlHanderMapping or some other more meaningful name. Especially =
with AbstractUrlHandlerMapping in addition to BeanNameUrlHandlerMapping, =
naming a concrete implementation UrlHandlerMapping seems inappropriate.

Of course, this would mean a name change that affects ControllerServlet =
context config files. But I think that we should prefer proper names and =
proper structure to backward compatibility, at least as long as there =
isn't an official release.

Juergen


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Monday, April 07, 2003 5:09 PM
To: spr...@li...
Subject: [Springframework-developer] Ordering HandlerMappings and other
beans


Hi Rod, everyone,

I've just developed a custom HandlerMapping strategy for one of our =
applications and faced the issue that I wanted to retrieve beans of a =
certain class from the ApplicationContext in a specifyable order. =
Looking for a solution, I've recognized that exactly the same issue =
occurs with HandlerMappings themselves too. Currently, ControllerServlet =
solves this via sorting by bean name ("a.urlMap", "b.urlMap"), but =
frankly, I've never particularly liked that solution.

So I've applied a new approach to both HandlerMapping order and the =
problem in the custom application. Details of the HandlerMapping =
solution follow:

- I've introduced a Ordered interface to com.interface21.core, featuring =
one single method "int getOrder()", and an associated OrderComparator. =
The getOrder() method simply returns an int value, higher value meaning =
greater in terms of sorting resp. lower priority. This is somewhat =
analogous to Servlet load-on-startup values. OrderComparator sorts by =
order value, treating non-Ordered objects as greatest resp. lowest =
priority.

- ControllerServlet now sorts HandlerMappings (and HandlerAdapters, for =
consistency's sake) by sorting them with OrderComparator, rather than by =
bean name. Non-Ordered instances are thus applied in an arbitrary order, =
but instances can choose to implement Ordered to be able to specify a =
higher priority. Of course, the obvious way is adding an "order" bean =
property with getter and setter, to allow specifying the order value in =
the ApplicationContext configuration.

- There's AbstractUrlHandlerMapping now, an abstract base class for =
url-based HandlerMapping implementations. In addition to refactored =
things like unified handler initialization code (propagating =
ApplicationContext and LocaleResolver) for both =
BeanNameUrlHandlerMapping and UrlHandlerMapping, it offers a =
property-based Ordered implementation.

An example snippet from an applicationContext.xml file:

	<bean name=3D"myUrlMap" =
class=3D"com.interface21.web.servlet.handler.UrlHandlerMapping">
		<property name=3D"order">0</property>
		<property name=3D"mappings">
			/example.do=3DexampleController
		</property>
	</bean>

	<bean name=3D"yourUrlMap" =
class=3D"com.interface21.web.servlet.handler.UrlHandlerMapping">
		<property name=3D"order">1</property>
		<property name=3D"mappings">
			/example.do=3D/exampleFormController
			/exampleForm.do=3DexampleFormController
		</property>
	</bean>

According to the order values, myUrlMap gets applied first, thus =
"/example.do" will lead to exampleController's execution. If one sets =
myUrlMap's order value to "2" or omits its order line, yourUrlMap will =
get applied first, thus "/example.do" will lead to =
exampleFormController's execution.

I consider this more elegant and more flexible than sorting by bean =
name. After all, servlets don't get started in the order of their name =
for a reason... ;-) Fortunately, an application developer doesn't have =
to care about the Ordered interface if he doesn't want to: A single =
HandlerMapping definition doesn't need to specify an order value, and a =
HandlerMapping implementation doesn't need to implement Ordered.

If noone objects, I will check in the changes promptly, as they go hand =
in hand with other things like the UrlHandlerMapping refactoring and =
some ControllerServlet polishing.

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



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] javadocs

[Isabelle M. <met...@pa...>]

Hi everyone,

I've started fixing the javadocs and there are 3 recurring problems :

(1) an @version tag without version number
(2) a package.html file that doesn't contain the proper html tags. Should be like this :

<html>
<head/>
<body>
blabla
</body>
</html>

(3) <a> tags where the href is not enclosed in quotes. Should be like this :
<a href="url">

Please try to avoid these errors in the future, fixing javadocs really isn't any fun.

Isabelle

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

RE: [Springframework-developer] StringUtils needs InternalErrorException

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

I've checked in the file you've just sent me. Everything should compile =
now. I guess that CVS isn't the most reliable piece of software in the =
world... ;-)

Juergen


-----Original Message-----
From: Isabelle Muszynski [mailto:met...@pa...]
Sent: Monday, April 07, 2003 5:45 PM
To: spr...@li...
Subject: Re: [Springframework-developer] StringUtils needs
InternalErrorException


Very bizarre, as I did an add of InternalErrorException, followed by a =
commit. I'm at work now, so don't have the time to figure out what went =
wrong. However, let me try to retrieve the missing file from my home pc =
and then I'll email it to you, and maybe you can do the add.

Isabelle


On Mon, Apr 07, 2003 at 05:15:04PM +0200, j=FCrgen h=F6ller [werk3AT] =
wrote:
> Isabelle,
>=20
> The version of StringUtils that you've checked in depends on a new =
InternalErrorException in the core package. But the latter isn't in CVS =
yet...
>=20
> Regards,
> Juergen
>=20
> P.S.:
> I've just seen that someone has already posted a SourceForge bug =
report for this.
>=20
>=20
> DI J=FCrgen H=F6ller
> Senior System Architect
> __________________________________
>=20
> werk3ATS - division systementwicklung
> part of werk3AT internetmedien oeg
>=20
> europaplatz 4
> A - 4020 linz
>=20
> 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
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20

--=20
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] StringUtils needs InternalErrorException

[Isabelle M. <met...@pa...>]

Very bizarre, as I did an add of InternalErrorException, followed by a commit. I'm at work now, so don't have the time to figure out what went wrong. However, let me try to retrieve the missing file from my home pc and then I'll email it to you, and maybe you can do the add.

Isabelle


On Mon, Apr 07, 2003 at 05:15:04PM +0200, jürgen höller [werk3AT] wrote:
> Isabelle,
> 
> The version of StringUtils that you've checked in depends on a new InternalErrorException in the core package. But the latter isn't in CVS yet...
> 
> Regards,
> Juergen
> 
> P.S.:
> I've just seen that someone has already posted a SourceForge bug report for this.
> 
> 
> 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
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

-- 
Isabelle Muszynski
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89

[Springframework-developer] BeanNameUrlHandlerMapping separator char

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

One more thing: I suggest to change the separator char for =
BeanNameUrlHandlerMapping URLs from "," to " ".

I consider blank the better separator for URLs, as it isn't allowed in a =
URL in any case and provides more obvious visual separation.

Any objections?

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

[Springframework-developer] StringUtils needs InternalErrorException

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

Isabelle,

The version of StringUtils that you've checked in depends on a new =
InternalErrorException in the core package. But the latter isn't in CVS =
yet...

Regards,
Juergen

P.S.:
I've just seen that someone has already posted a SourceForge bug report =
for this.


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

[Springframework-developer] Ordering HandlerMappings and other beans

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

Hi Rod, everyone,

I've just developed a custom HandlerMapping strategy for one of our =
applications and faced the issue that I wanted to retrieve beans of a =
certain class from the ApplicationContext in a specifyable order. =
Looking for a solution, I've recognized that exactly the same issue =
occurs with HandlerMappings themselves too. Currently, ControllerServlet =
solves this via sorting by bean name ("a.urlMap", "b.urlMap"), but =
frankly, I've never particularly liked that solution.

So I've applied a new approach to both HandlerMapping order and the =
problem in the custom application. Details of the HandlerMapping =
solution follow:

- I've introduced a Ordered interface to com.interface21.core, featuring =
one single method "int getOrder()", and an associated OrderComparator. =
The getOrder() method simply returns an int value, higher value meaning =
greater in terms of sorting resp. lower priority. This is somewhat =
analogous to Servlet load-on-startup values. OrderComparator sorts by =
order value, treating non-Ordered objects as greatest resp. lowest =
priority.

- ControllerServlet now sorts HandlerMappings (and HandlerAdapters, for =
consistency's sake) by sorting them with OrderComparator, rather than by =
bean name. Non-Ordered instances are thus applied in an arbitrary order, =
but instances can choose to implement Ordered to be able to specify a =
higher priority. Of course, the obvious way is adding an "order" bean =
property with getter and setter, to allow specifying the order value in =
the ApplicationContext configuration.

- There's AbstractUrlHandlerMapping now, an abstract base class for =
url-based HandlerMapping implementations. In addition to refactored =
things like unified handler initialization code (propagating =
ApplicationContext and LocaleResolver) for both =
BeanNameUrlHandlerMapping and UrlHandlerMapping, it offers a =
property-based Ordered implementation.

An example snippet from an applicationContext.xml file:

	<bean name=3D"myUrlMap" =
class=3D"com.interface21.web.servlet.handler.UrlHandlerMapping">
		<property name=3D"order">0</property>
		<property name=3D"mappings">
			/example.do=3DexampleController
		</property>
	</bean>

	<bean name=3D"yourUrlMap" =
class=3D"com.interface21.web.servlet.handler.UrlHandlerMapping">
		<property name=3D"order">1</property>
		<property name=3D"mappings">
			/example.do=3D/exampleFormController
			/exampleForm.do=3DexampleFormController
		</property>
	</bean>

According to the order values, myUrlMap gets applied first, thus =
"/example.do" will lead to exampleController's execution. If one sets =
myUrlMap's order value to "2" or omits its order line, yourUrlMap will =
get applied first, thus "/example.do" will lead to =
exampleFormController's execution.

I consider this more elegant and more flexible than sorting by bean =
name. After all, servlets don't get started in the order of their name =
for a reason... ;-) Fortunately, an application developer doesn't have =
to care about the Ordered interface if he doesn't want to: A single =
HandlerMapping definition doesn't need to specify an order value, and a =
HandlerMapping implementation doesn't need to implement Ordered.

If noone objects, I will check in the changes promptly, as they go hand =
in hand with other things like the UrlHandlerMapping refactoring and =
some ControllerServlet polishing.

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

Re: [Springframework-developer] build file

[Rod J. <rod...@in...>]

> I saw a post in the archives about potentially making use of Maven - is
> that still a possibility?

Probably not for 1.0, due to lack of time. Also, some concerns about the
startup time of Maven, although running Maven "interactively" is possible.
My initial enthusiasm for Maven has cooled a bit.

I have a Maven project file that I haven't checked in. It is out of date and
incomplete, but maybe I should check it in if anyone is interested.

A volunteer to get Maven happening would be good! It would certainly be
handy to generate the website.

Regards,
Rod

Re: [Springframework-developer] build file

[Rod J. <rod...@in...>]

Fine by me. Also, I think the target that builds a single Jar doesn't put it
in the dist directory. It would be good to fix that too.

Rod

----- Original Message -----
From: "Isabelle Muszynski" <met...@pa...>
To: <spr...@li...>
Sent: Saturday, April 05, 2003 7:48 PM
Subject: [Springframework-developer] build file


> Hi everyone,
>
> Can I set failonerror to true in the build file, otherwise the full target
will build the jar file if the compile fails.
>
> Isabelle
>
> --
> Isabelle Muszynski
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer