springframework-developer — Spring Framework developers list

RE: [Springframework-developer] purpose of code in Errors.rejectValue()

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

> I'm not so keen on this. I think when throwing an exception,=20
> code should only provide an error code. It won't necessarily=20
> know about how messages are
> resolved: this is a presentation issue.

I agree completely. Message resolution should happen at model =
aggregation or view rendering time.

> Maybe a compromise would be to have a fallback approach, in=20
> which the ErrorResolver implementation, if it failed to look=20
> up a message for an exception's error code, looked for a=20
> ResourceBundle called messages.properties in the same package=20
> as the exception. I think this would allow what you propose,=20
> but still permit the use of an override at framework level.

I don't really like such a fallback. Hardcoding to a resource bundle =
here would kind of violate Spring's message source approach. What about =
allowing for a dedicated error message source, configured via the =
application context and specified by the error resolver?

> Btw, the present approach isn't limited to a single message=20
> source: MessageSources nest.

At least in theory... ;-)

Seriously, I've just tried it, and it didn't work with =
ResourceBundleMessageSources, due to a ResourceBundle's =
MissingResourceException going up to AbstractNestingMessageSource and =
being converted to NoSuchMessageException there.

A little fix in ResourceBundleMessageSource's resolve method, namely =
catching the MissingResourceException and converting it to a null return =
value, corrects this. I've just committed it - now MessageSources do =
indeed nest! :-)

Juergen

RE: [Springframework-developer] Release schedule

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

Paul,

I must admit I haven't thought about the internals of Struts support =
earlier. But now that I've reviewed your plugin, I am aware of how easy =
this actually is. We just need to initialize the ApplicationContext and =
expose it to the ServletContext, and off we go writing Struts actions =
that use Spring beans via retrieving the ApplicationContext from the =
ServletContext.

Facing this simple way, I wonder if we need explicit Struts support at =
all, at least in the technical sense. Isn't setting up a standard =
ContextLoaderServlet or ContextLoaderListener in web.xml just as easy as =
registering a Struts-specific plugin in struts-config.xml? The Struts =
plugin doesn't seem to add any specific handling, as the ServletContext =
contained by the ActionServlet instance should be equal to the standard =
ServletContext of the web application.

The only obvious difference seems to be the attribute name, which is not =
meant for manual usage in standard Spring. But Struts actions could =
simply retrieve the current ApplicationContext via =
com.interface21.web.context.support.WebApplicationContextUtils.getWebAppl=
icationContext(ServletContext), using Spring's standard attribute name =
underneath.

So, should we adopt my proposed pattern? Its major advantage is its =
simplicity - it does not need any specific Struts support at all, =
especially no binary dependency on Struts classes within Spring. And it =
should work nicely, at the same level of convenience as the Struts =
plugin. Is there any added value of the latter that I am missing?

Finally, with Spring's newly refactored ContextLoader class, a minimal =
Plugin implementation should do the job now, analogous to the =
ContextLoaderListener implementation - if one really needs configuration =
via struts-config.xml. Instead of replicating the initialization code, =
the following should be enough:

  public void init(ActionServlet servlet, ModuleConfig config) throws =
ServletException {
    ContextLoader.initContext(servlet.getServletContext(), =
contextClass);
  }

But still, I consider configuration via web.xml equally simple.

Regards,
Juergen


> -----Original Message-----
> From: Paul Feaviour [mailto:pau...@ho...]=20
> Sent: Thursday, March 06, 2003 12:06 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Release schedule
>=20
>=20
> Juergen/group
>=20
> Wow - I am very impressed with the amount of work you are=20
> contributing towards the Spring framework - if only I could=20
> find the time I would love to be more active.
>=20
> Personally, I think it would help if tasks were cleary=20
> defined and assigned to individuals - I am unsure what areas=20
> need looking at and am conscience that I may be duplicating=20
> effort if I just dive in.  I know that tasks are discussed=20
> within this list but this should be documented  - or does=20
> this go against the open source idealogy.
>=20
> BTW I have attached a struts plugin that I have written and=20
> am using with success - it needs reviewing.
>=20
> Here is a brief description of its use - I assume struts familarity:
>=20
> A Struts PlugIn can be used to provide close integration with=20
> Spring's bean based infrastructure.  The root=20
> com.interface21.web.context.WebApplicationContext object,=20
> which defines JavaBeans and their relationships ,can be added=20
> to a web application's ServletContext by this PlugIn, as an=20
> alternative to using the ContextLoaderServlet.
>=20
> PlugIn modules can be configured using the <plug-in> element=20
> in the struts-config.xml file.  Classes that implement the=20
> PlugIn interface must have a zero-argument constructor,=20
> configuration is performed by providing standard JavaBeans=20
> property setter methods.
>=20
> The PlugIn requires a single configuration parameter to be=20
> provided in the deployment descriptor, contextClass. This=20
> parameter is the class name of the WebApplicationContext=20
> implementation to provide a context for this
> application, in this case XmlWebApplicationContext.   The=20
> PlugIn merely
> instantiates the class and provides it with the current=20
> ServletContext object.
>=20
> <plug-in className=3D"com.phoenix.web.context.ContextLoaderPlugin">
>     <set-property property=3D"contextClass"=20
> =
value=3D"com.interface21.web.context.support.XmlWebApplicationContext"/>
> </plug-in>
>=20
> The WebApplicationContext requires a configUrl to be set in=20
> the web.xml file.  This is the URL to the configuration file=20
> that defines the business objects and their relationships. =20
> These are exposed as JavaBeans to classes in the web=20
> application framework, servlet filters and JSP custom tags.
>=20
> <context-param>
>     <param-name>configUrl</param-name>
>     <param-value>/WEB-INF/applicationContext.xml</param-value>
> </context-param>
>=20
> Struts Actions can access these business objects by looking=20
> up the WebApplicationContext in the ServletContext.
>=20
> Note:  Certain bean names have special significance and one=20
> must be provided in the configuration file, "messageSource". =20
> This defines an internationalizable repository for errors and=20
> other messages.  Even if the application uses the Struts=20
> resource bundle, this is still required, along with the=20
> messages.properties file in /WEB-INF/classes.
>=20
> <bean name=3D"messageSource"=20
> class=3D"com.interface21.context.support.ResourceBundleMessageSource">
>     <property name=3D"basename">messages</property>
> </bean>
>=20
>=20
> ----- Original Message -----
> From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Thursday, March 06, 2003 10:18 AM
> Subject: [Springframework-developer] Release schedule
>=20
>=20
> Hi committers,
>=20
> We should try to approach a 0.8 release ASAP, as the lack of=20
> a formal distribution definitely hinders Spring adopting. IMO=20
> we should aim at end of March.
>=20
> Unfortunately, the lack of documentation is a major issue:=20
> Currently, a potential user should have both Rod's book and=20
> the framework sources. I consider polishing JavaDoc comments=20
> and including generated JavaDoc a must, already for 0.8.=20
> Separate online documentation will be a must for 1.0, but not=20
> earlier, I guess. Any volunteers for either?
>=20
> The further schedule will probably consist of 0.9 at end of=20
> April and 1.0 around June. Of course, the actual dates will=20
> be determined by Spring's quality and stability, not by a=20
> deadline. Nevertheless, I have the urge to proceed release-oriented.
>=20
> IMHO, we are easily feature-complete for 0.8 now, as=20
> multipart request handling can also wait until 0.9. Beyond=20
> that, we should think about further must-haves for 1.0. The=20
> Struts plugin comes to my mind, for example, and better test=20
> coverage and homogeneous code style. Beyond the framework=20
> itself, we will need example apps, and a nice little website=20
> with some sort of "project identity".
>=20
> What do you think?
>=20
> Regards,
> Juergen
>=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
> f.  +43 (0) 732 71 65 29 3
> jue...@we...
> www.werk3at.com
> __________________________________
> werk3ATS - WIR ENTWICKELN ERFOLG
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of=20
> TotalView, The debugger for complex code. Debugging C/C++=20
> programs can leave you feeling lost and disoriented.=20
> TotalView can help you find your way. Available on major UNIX=20
> and Linux platforms. Try it free. www.etnus.com=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20

Re: [Springframework-developer] Release schedule

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

The schedule sounds good to me as well. 
 jürgen_höller_[werk3AT] <jue...@we...> wrote: Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal distribution definitely hinders Spring adopting. IMO we should aim at end of March.

Unfortunately, the lack of documentation is a major issue: Currently, a potential user should have both Rod's book and the framework sources. I consider polishing JavaDoc comments and including generated JavaDoc a must, already for 0.8. Separate online documentation will be a must for 1.0, but not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and 1.0 around June. Of course, the actual dates will be determined by Spring's quality and stability, not by a deadline. Nevertheless, I have the urge to proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request handling can also wait until 0.9. Beyond that, we should think about further must-haves for 1.0. The Struts plugin comes to my mind, for example, and better test coverage and homogeneous code style. Beyond the framework itself, we will need example apps, and a nice little website with some sort of "project identity".

What do you think?

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
f. +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
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] Release schedule

[William G. T. Jr. <wg...@rc...>]

JavaOne is also mid June...

Rod Johnson wrote:
> I agree: I think a release schedule is very important. Of course it's hard
> to commit to deadlines for open source projects, but if we want people to
> start using Spring we need to give them a roadmap, and a download ASAP.
> 
> I think the API is unlikely to change much from now to 1.0, although some
> internals might change a bit (e.g. JDBC changes), so I think we're nearly
> ready for 0.8 now.
> 
> I pretty much agree with Juergen re timescales.
> 
> 0.8: download, polished JavaDoc, with better package.html files. I've been
> using EclipseUML (modelling plugin for Eclipse) and I'm impressed. I might
> try to add some class diagrams to package.html files. How about we say March
> 23 for this (2 weeks + a weekend), as I think we're fairly close and there's
> huge value in having a download.
> We will need to coordinate tasks closely. I'm not sure how best to do this.
> Yann, you mentioned SourceForge facilities: can you please help suggest how
> best to use them, as I'm unsure.
> -- Thomas, were are with we your JDBC changes? This is perhaps the biggest
> area of change nearly ready to go --
> 
> 0.9: Whatever we have one month later (late April). A progress release.
> Would be good to get Struts plugin in here, although maybe we could even do
> that for 0.8.
> 
> 1.0 beta: Mid May. Should be exactly what we hope to have in 1.0, possibly
> with incomplete docs.
> 
> 1.0: Late May. I'm talking at TSS symposium in late June and I think it
> would be great if we were at 1.0 by then, as I'd like to mention Spring. We
> need:
> - tutorial
> - sample app (yes, maybe the first one could be based on the book's)
> - overview docs of areas such as JDBC/Web
> - website as Juergen says
> - significantly improved test coverage. We're currently at 44%: I would like
> to see >= 60% by 1.0, and hopefully a steady increase up till then.
> 
> No AOP in any of these releases. I'm hoping to knock that into shape over
> the next 3 weeks, but anyone who's interested can check out CVS.
> 
> Outstanding issues:
> - Packaging, regarding the old EJB/WAR class loader issues when deploying
> WAR+EJB EARs. Hopefully the present packaging will work fine for 0.8. Things
> may get tougher with Thomas's new JDBC stuff.
> 
> Regards,
> Rod
> 
> ----- Original Message -----
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Thursday, March 06, 2003 10:18 AM
> Subject: [Springframework-developer] Release schedule
> 
> 
> Hi committers,
> 
> We should try to approach a 0.8 release ASAP, as the lack of a formal
> distribution definitely hinders Spring adopting. IMO we should aim at end of
> March.
> 
> Unfortunately, the lack of documentation is a major issue: Currently, a
> potential user should have both Rod's book and the framework sources. I
> consider polishing JavaDoc comments and including generated JavaDoc a must,
> already for 0.8. Separate online documentation will be a must for 1.0, but
> not earlier, I guess. Any volunteers for either?
> 
> The further schedule will probably consist of 0.9 at end of April and 1.0
> around June. Of course, the actual dates will be determined by Spring's
> quality and stability, not by a deadline. Nevertheless, I have the urge to
> proceed release-oriented.
> 
> IMHO, we are easily feature-complete for 0.8 now, as multipart request
> handling can also wait until 0.9. Beyond that, we should think about further
> must-haves for 1.0. The Struts plugin comes to my mind, for example, and
> better test coverage and homogeneous code style. Beyond the framework
> itself, we will need example apps, and a nice little website with some sort
> of "project identity".
> 
> What do you think?
> 
> Regards,
> Juergen

Re: [Springframework-developer] purpose of code in Errors.rejectValue()

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

Tony,

> Very quickly though, in response to your question of "Wouldn't this mean
extending MessageSource with overloaded getMessage versions that feature an
errorArgs parameter?".  Yes,
> my changes initially started out with changing the MessageSource interface
(and the implementations) to handle passing in an "Object[] errorArgs"
param.
I'm fine with this.

> From there it let to some changes elsewhere, including looking at the
Errors object.
> One thing that should probably discuss is the concept of a single message
source.
> Initially I though a single message source would be fine, but as this is a
framework I've since
> changed my opinion.  My opinion now is this.  We can leave each Context to
have it's
> own single message source, but we can allow configuration (using the
framework's bean
> factory code) to allow other classes to have whatever message SOURCES they
need.
> Let's look at this as an example.  One of my code proposals is to add an
Exception class into the framework
> that will be able to resolve messages from a ResourceBundle.
I'm not so keen on this. I think when throwing an exception, code should
only provide an error code. It won't necessarily know about how messages are
resolved: this is a presentation issue.

Maybe a compromise would be to have a fallback approach, in which the
ErrorResolver implementation, if it failed to look up a message for an
exception's error code, looked for a ResourceBundle called
messages.properties in the same package as the exception. I think this would
allow what you propose, but still permit the use of an override at framework
level.

Btw, the present approach isn't limited to a single message source:
MessageSources nest.

> BTW - I think we should have 2 overloads for the methods that allow a
Locale to be passed in.
> If it is passed in we use it.  If it is not passed in, fall back to the
"defaultLocale".
> Currently the way I've coded the "defaultLocale" is whatever Java resolves
to.  This needs to be changed
> to work with the changes that have been made for the Locale to be passed
in from HTTPRequests.
> This definately needs to be discussed (shouldn't be a big deal).
Sounds reasonable.

Regards,
Rod

Re: [Springframework-developer] Release schedule

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

I agree: I think a release schedule is very important. Of course it's hard
to commit to deadlines for open source projects, but if we want people to
start using Spring we need to give them a roadmap, and a download ASAP.

I think the API is unlikely to change much from now to 1.0, although some
internals might change a bit (e.g. JDBC changes), so I think we're nearly
ready for 0.8 now.

I pretty much agree with Juergen re timescales.

0.8: download, polished JavaDoc, with better package.html files. I've been
using EclipseUML (modelling plugin for Eclipse) and I'm impressed. I might
try to add some class diagrams to package.html files. How about we say March
23 for this (2 weeks + a weekend), as I think we're fairly close and there's
huge value in having a download.
We will need to coordinate tasks closely. I'm not sure how best to do this.
Yann, you mentioned SourceForge facilities: can you please help suggest how
best to use them, as I'm unsure.
-- Thomas, were are with we your JDBC changes? This is perhaps the biggest
area of change nearly ready to go --

0.9: Whatever we have one month later (late April). A progress release.
Would be good to get Struts plugin in here, although maybe we could even do
that for 0.8.

1.0 beta: Mid May. Should be exactly what we hope to have in 1.0, possibly
with incomplete docs.

1.0: Late May. I'm talking at TSS symposium in late June and I think it
would be great if we were at 1.0 by then, as I'd like to mention Spring. We
need:
- tutorial
- sample app (yes, maybe the first one could be based on the book's)
- overview docs of areas such as JDBC/Web
- website as Juergen says
- significantly improved test coverage. We're currently at 44%: I would like
to see >= 60% by 1.0, and hopefully a steady increase up till then.

No AOP in any of these releases. I'm hoping to knock that into shape over
the next 3 weeks, but anyone who's interested can check out CVS.

Outstanding issues:
- Packaging, regarding the old EJB/WAR class loader issues when deploying
WAR+EJB EARs. Hopefully the present packaging will work fine for 0.8. Things
may get tougher with Thomas's new JDBC stuff.

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, March 06, 2003 10:18 AM
Subject: [Springframework-developer] Release schedule


Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal
distribution definitely hinders Spring adopting. IMO we should aim at end of
March.

Unfortunately, the lack of documentation is a major issue: Currently, a
potential user should have both Rod's book and the framework sources. I
consider polishing JavaDoc comments and including generated JavaDoc a must,
already for 0.8. Separate online documentation will be a must for 1.0, but
not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and 1.0
around June. Of course, the actual dates will be determined by Spring's
quality and stability, not by a deadline. Nevertheless, I have the urge to
proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request
handling can also wait until 0.9. Beyond that, we should think about further
must-haves for 1.0. The Struts plugin comes to my mind, for example, and
better test coverage and homogeneous code style. Beyond the framework
itself, we will need example apps, and a nice little website with some sort
of "project identity".

What do you think?

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


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

[Springframework-developer] sample application

[Bob M. <bo...@ex...>]

 I think the first sample app shoud be the small skeleton code that came with the book. It should be deployable in Tomcat and not require JBoss or even a database. Has anyone converted this to work with the current build? -Bob> For a sample app,  could we use the one that came with the book?

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

Re: [Springframework-developer] Release schedule

[William G. T. Jr. <wg...@rc...>]

Sounds like a plan to me.  However, I lean more towards a 1.0 release in 
April and pushing new features to a 1.1 release.  For a sample app, 
could we use the one that came with the book?

jürgen höller [werk3AT] wrote:
> Hi committers,
> 
> We should try to approach a 0.8 release ASAP, as the lack of a formal distribution definitely hinders Spring adopting. IMO we should aim at end of March.
> 
> Unfortunately, the lack of documentation is a major issue: Currently, a potential user should have both Rod's book and the framework sources. I consider polishing JavaDoc comments and including generated JavaDoc a must, already for 0.8. Separate online documentation will be a must for 1.0, but not earlier, I guess. Any volunteers for either?
> 
> The further schedule will probably consist of 0.9 at end of April and 1.0 around June. Of course, the actual dates will be determined by Spring's quality and stability, not by a deadline. Nevertheless, I have the urge to proceed release-oriented.
> 
> IMHO, we are easily feature-complete for 0.8 now, as multipart request handling can also wait until 0.9. Beyond that, we should think about further must-haves for 1.0. The Struts plugin comes to my mind, for example, and better test coverage and homogeneous code style. Beyond the framework itself, we will need example apps, and a nice little website with some sort of "project identity".
> 
> What do you think?
> 
> Regards,
> Juergen

Re: [Springframework-developer] Release schedule

[Paul F. <pau...@ho...>]

Juergen/group

Wow - I am very impressed with the amount of work you are contributing
towards the Spring framework - if only I could find the time I would love to
be more active.

Personally, I think it would help if tasks were cleary defined and assigned
to individuals - I am unsure what areas need looking at and am conscience
that I may be duplicating effort if I just dive in.  I know that tasks are
discussed within this list but this should be documented  - or does this go
against the open source idealogy.

BTW I have attached a struts plugin that I have written and am using with
success - it needs reviewing.

Here is a brief description of its use - I assume struts familarity:

A Struts PlugIn can be used to provide close integration with Spring's bean
based infrastructure.  The root
com.interface21.web.context.WebApplicationContext object, which defines
JavaBeans and their relationships ,can be added to a web application's
ServletContext by this PlugIn, as an alternative to using the
ContextLoaderServlet.

PlugIn modules can be configured using the <plug-in> element in the
struts-config.xml file.  Classes that implement the PlugIn interface must
have a zero-argument constructor, configuration is performed by providing
standard JavaBeans property setter methods.

The PlugIn requires a single configuration parameter to be provided in the
deployment descriptor, contextClass. This parameter is the class name of the
WebApplicationContext implementation to provide a context for this
application, in this case XmlWebApplicationContext.   The PlugIn merely
instantiates the class and provides it with the current ServletContext
object.

<plug-in className="com.phoenix.web.context.ContextLoaderPlugin">
    <set-property property="contextClass"
value="com.interface21.web.context.support.XmlWebApplicationContext"/>
</plug-in>

The WebApplicationContext requires a configUrl to be set in the web.xml
file.  This is the URL to the configuration file that defines the business
objects and their relationships.  These are exposed as JavaBeans to classes
in the web application framework, servlet filters and JSP custom tags.

<context-param>
    <param-name>configUrl</param-name>
    <param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>

Struts Actions can access these business objects by looking up the
WebApplicationContext in the ServletContext.

Note:  Certain bean names have special significance and one must be provided
in the configuration file, "messageSource".  This defines an
internationalizable repository for errors and other messages.  Even if the
application uses the Struts resource bundle, this is still required, along
with the messages.properties file in /WEB-INF/classes.

<bean name="messageSource"
class="com.interface21.context.support.ResourceBundleMessageSource">
    <property name="basename">messages</property>
</bean>


----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, March 06, 2003 10:18 AM
Subject: [Springframework-developer] Release schedule


Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal
distribution definitely hinders Spring adopting. IMO we should aim at end of
March.

Unfortunately, the lack of documentation is a major issue: Currently, a
potential user should have both Rod's book and the framework sources. I
consider polishing JavaDoc comments and including generated JavaDoc a must,
already for 0.8. Separate online documentation will be a must for 1.0, but
not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and 1.0
around June. Of course, the actual dates will be determined by Spring's
quality and stability, not by a deadline. Nevertheless, I have the urge to
proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request
handling can also wait until 0.9. Beyond that, we should think about further
must-haves for 1.0. The Struts plugin comes to my mind, for example, and
better test coverage and homogeneous code style. Beyond the framework
itself, we will need example apps, and a nice little website with some sort
of "project identity".

What do you think?

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


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

[Springframework-developer] Release schedule

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

Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal =
distribution definitely hinders Spring adopting. IMO we should aim at =
end of March.

Unfortunately, the lack of documentation is a major issue: Currently, a =
potential user should have both Rod's book and the framework sources. I =
consider polishing JavaDoc comments and including generated JavaDoc a =
must, already for 0.8. Separate online documentation will be a must for =
1.0, but not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and =
1.0 around June. Of course, the actual dates will be determined by =
Spring's quality and stability, not by a deadline. Nevertheless, I have =
the urge to proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request =
handling can also wait until 0.9. Beyond that, we should think about =
further must-haves for 1.0. The Struts plugin comes to my mind, for =
example, and better test coverage and homogeneous code style. Beyond the =
framework itself, we will need example apps, and a nice little website =
with some sort of "project identity".

What do you think?

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

[Springframework-developer] HTML escaping and other changes to the web package

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

Hi everybody,

I've just finished the HTML escaping support and some minor tweaks of =
the web package:

- Reworked tags: Spring's custom tags have an optional boolean =
"htmlEscape" property now, and there's a new htmlEscape tag for setting =
a default value. For escaped Errors as returned by the hasBindErrors =
tag, an Errors proxy is used, adding HTML escaping for affected methods. =


- RequestContextUtils: JSP expressions can use simple utility methods in =
RequestContextUtils for retrieving either escaped or plain versions of =
Errors and messages, and the current Locale. ControllerServlet exposes a =
locale attribute to the request now, analogous to the =
WebApplicationContext. I've dissolved =
com.interface21.web.bind.BindUtils, as its functionality is now covered =
by RequestContextUtils.

- RequestContext: An alternative approach, also suitable for Velocity =
and JSTL, is using the new RequestContext and reading its properties. A =
RequestContext instance can automatically get added as a request =
attribute with a specified name (for convenient access) via =
AbstractViews's new "requestContextAttribute" property.

- Startup simplification: FrameworkServlet and thus ControllerServlet =
implictly call ContextLoader now if no WebApplicationContext has been =
initialized previously. This means that explictly declaring =
ContextLoaderListener or ContextLoaderServlet in web.xml is entirely =
optional now, at least if you do have one or more ControllerServlet =
declarations with load-on-startup!

- Context refresh: ApplicationContext has a new ContextRefreshedEvent =
that gets published after initializing all beans. This allows for =
implementing a respective listener bean that performs some startup work =
using other beans, therefore needing all beans preinitialized instead of =
just itself. An example is a custom configurer that reads some =
administration config file outside of the application context and =
populates respective properties of various beans.

- Locale resolution: Correct locale attribute usage in all view =
implementations.

- Validation: Slightly polished API.

Looking forward to your feedback!

BTW, there's only one of my proposals left now: multipart request =
handling. I will try to start work on it next week - expect a finished =
initial solution the week after.

Regards,
Juergen

RE: [Springframework-developer] purpose of code in Errors.rejectV alue()

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

Juergen,

Please see inline.

>=20
> Spring's validator framework is definitely meant to be reusable =
across
> presentation and business logic layers. This is a major USP compared =
to
> Struts' web-centric validation support.
[John Cavacas]=20

Agreed. Which is why I am exploring its use.
>=20
> You can define validator beans in your application context, e.g. a
> "userValidator" bean that implements =
com.interface21.validation.Validator
> and supports your User class. The bean definition can configure the
> validator via its properties. You can assign this bean to respective
> CommandController/FormController implementations as "validator" bean
> reference easily, for web controller validation. This is shown in =
chapter
> 12 of Rod's book.
>=20
[John Cavacas]=20

This is exactly what I have done. However I haven't defined it in a
CommandController/FormController as of yet. As it stands now, the only =
usage
of the validator is in my unit tests, but like you said I will be able =
to
just make it available to my controller and use it.

> Beyond usage in web controllers, you can assign your validator bean =
to any
> business logic services too, easily via bean reference if your =
services
> are registered as beans in your application context. For services =
outside
> of the application context, you could assign the validator bean =
manually
> by getting a reference to the application context, looking up the =
bean,
> and setting it to your service instance. All of this would work in a
> standalone application too, if it utilizes a Spring application =
Context.
>=20
[John Cavacas]=20

Now this is the problem that I am dealing with currently (well I =
haven't had
time to look at it in the past couple of days). My business object is a =
bean
and it is configured by the framework. Let me explain a bit more about =
my
current design. My business object is simply a JavaBean that uses a DAO
object (which in turn makes use of the JDBC and bean Framework). You =
are
right in saying that I can make the validator object also available to =
the
Business Object, however the Business Object is the one responsible for
using the DAO to find out for example, if an email address is already =
in the
database. How do you suggest that the validator have access to that =
kind of
functionality/data? Should it have a reference to the DAO as well? =
Should it
call back the Business Object? That's the issue that I am dealing with =
as it
seems that the separation of concerns becomes mixed up if I do that.=20

Could you perhaps explain how you would solve this problem in more =
detail?
Or rather how the framework Validator can be reused across multiple =
layers.
Maybe I'm just not seeing it.



> Therefore, I don't see a need for validator plug-ins or the like. =
This
> demonstrates the power of the bean factory concept: You can achieve =
so
> much with it so easily.
>=20
> BTW, I assume that the unfinished class in Spring's validation =
package
> that you mentioned is ValidationUtils. This class is meant to be a =
simple
> static utility class that provides low-level validation checks to =
ease
> Validator implementations. Don't confuse this with your Validator
> implementations and their reusability across multiple layers.
[John Cavacas]=20

That was the class that I was referring too and I realize it's not =
finished.

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. =A9 2002
Sapiens Americas Corp.

RE: [Springframework-developer] purpose of code in Errors.rejectValue()

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

Juergen, 
You have some very valid points.  Unfortuately I have limited time this morning to reply with any detail.  I will respond more tonight. 
Very quickly though, in response to your question of "Wouldn't this mean extending MessageSource with overloaded getMessage versions that feature an errorArgs parameter?".  Yes,
my changes initially started out with changing the MessageSource interface (and the implementations) to handle passing in an "Object[] errorArgs" param.
From there it let to some changes elsewhere, including looking at the Errors object. 
One thing that should probably discuss is the concept of a single message source.
Initially I though a single message source would be fine, but as this is a framework I've since
changed my opinion.  My opinion now is this.  We can leave each Context to have it's
own single message source, but we can allow configuration (using the framework's bean 
factory code) to allow other classes to have whatever message SOURCES they need. 
Let's look at this as an example.  One of my code proposals is to add an Exception class into the framework
that will be able to resolve messages from a ResourceBundle.  The actual code
for doing this resides in a "MessageSourceHelper" class, that implements the MessageSource,
ParameterizableErrorCoded (new subint of ErrorCoded that takes errorArgs), 
and ApplicationContextAware (for a callback from the context after a bean gets loaded into
the context).  This helper can be used by anyone that wishes to gain access to a MessageSource.
In my case, an abstract class "NestedCheckedExceptionWithMsgSource" knows how to forward
calls to this helper to resolve messages. 
It's quite possible that for this new Exception class that the user wants to isolate
certain types of messages into various text files.  So for example messages with
packages like the following might come from various sources:
com.int21      --> File A
com.int21.core    --> File B
com.int21.core.NestedCheckedException --> File C
com.int21.core.subpack   --> File D 
It's my proposal then, to allow configuration in the applicationContext.xml file
to create a "tree" hierarchy of what file gets associated with what package or class 
you are dealing with.  BTW - This Hierarchy code is modeled on how log4j does things 
and will be ported from it.  Unlike how the user creates a logger in log4j (ie: Logger = new Logger(Clazz.class.getName());
the MessageSourceHelper's "private Object controledBy" object name will be internally used
as the key for what file to resolve to. 

BTW - I think we should have 2 overloads for the methods that allow a Locale to be passed in.
If it is passed in we use it.  If it is not passed in, fall back to the "defaultLocale".
Currently the way I've coded the "defaultLocale" is whatever Java resolves to.  This needs to be changed
to work with the changes that have been made for the Locale to be passed in from HTTPRequests.
This definately needs to be discussed (shouldn't be a big deal). 

Let me formalize my thoughts a bit more tonight to give you a better response.  I can also send
over the changes that I have to you so we can work through an integrated solution. 
Tony 

  
 jürgen_höller_[werk3AT] <jue...@we...> wrote: Hi Tony,

Regarding your proposed changes to the Errors interface:

> Right now, I believe the API to obtaining messages for 
> anything in the framework is limited in 2 ways:
> 1) Does not allow parameters to be passed to it.
> 2) Some of the APIs do not allow a Locale to be passed into them (the
> Errors.rejectValue(...) is a good example.
> 
> My changes should address both these issues. Also, I am 
> attempting to add a subclass to the NestedException class 
> (that merely calls a helper
> object) that will allow Exceptions themselves to obtain their 
> messages from a ResourceBundle.

> rejectValue(String field, String errorCode, String message)
> rejectValue(String field, Locale locale, String errorCode, Object[] errorArgs, String defaultMessage)

You're right concerning the opportunity for message arguments. But I'm not sure about resolving the message from some specific error messages file, completely separated from the ApplicationContext and its MessageSource. Tbis would be inconsistent with the rest of Spring's message handling.

What do you intend to achieve with the Locale parameter to rejectValue? Do you intend to resolve the message immediately? This is not what localized messages is about. You need to resolve the message with the display locale, i.e. the locale of the user that actually sees the message.

If you simply want to generate a message including message arguments for a single language, then do so in your validation code and give your completed String result to the simple rejectValue version. The errorCode can be used for a short general identifier instead of a message key, as you've pointed out.

If you want to have localized messages with message arguments, then use the rejectValue version with errorArgs: The errorCode has to match the MessageSource key (i.e. ResourceBundle key in most cases) but simply gets stored, and so do the errorArgs. The final message gets constructed by the user of the Errors instance, e.g. the BindTag instance that prepares the Errors state for web UI usage via BindStatus. So the rejectValue implementation must not try to construct the final message, as it is not and should not be aware of the current user's Locale.

Therefore, the signatures should rather look as follows (note: no Locale parameter):
- rejectValue(String field, String errorCode, String message)
- rejectValue(String field, String errorCode, Object[] errorArgs, String defaultMessage)

Finally, how do you intend to merge the message from the resource bundle with the error arguments? Keep in mind that this should not happen in the rejectValue implementation! Taking BindTag as example again: Currently it simply tries to resolve the errorCode and the given message via the ApplicationContext's MessageSource support. How do you intend to make this work with error arguments? Wouldn't this mean extending MessageSource with overloaded getMessage versions that feature an errorArgs parameter?

Let's discuss this issue before you get your stuff into CVS, for clarity's sake. I've also made some changes to the Errors approach (as you're probably aware), especially for usage by the web package, so we should definitely synchronize our efforts!

Regards,
Juergen


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] purpose of code in Errors.rejectV alue()

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

Tony, John,

<quote>
To be honest, I'm not as familar with the Validator pattern. =20
From my recollection of that chapter in the book, I thought
Rod advocated having a separate object that contained all validation =
logic that both
the Business Object layer, and the Controller could call.  Better to =
have Rod
field that question.

[John Cavacas] That was my understanding as well in regards to the =
validator interface from reading the book. But unless I missed something =
obvious, I just don't see how that would work, especially from the =
Business Object layer side of things. I've been playing around with some =
ideas as well to come up with a way to have common "validator plug-ins". =
I saw a class in spring that I think is ment for that purpose, but it =
looks like an unfinished thought. I think that using the bean framework =
and maybe a change in the validator interface, could make that concept a =
reality, and it's something that I want to explore.
</quote>

Spring's validator framework is definitely meant to be reusable across =
presentation and business logic layers. This is a major USP compared to =
Struts' web-centric validation support.

You can define validator beans in your application context, e.g. a =
"userValidator" bean that implements =
com.interface21.validation.Validator and supports your User class. The =
bean definition can configure the validator via its properties. You can =
assign this bean to respective CommandController/FormController =
implementations as "validator" bean reference easily, for web controller =
validation. This is shown in chapter 12 of Rod's book.

Beyond usage in web controllers, you can assign your validator bean to =
any business logic services too, easily via bean reference if your =
services are registered as beans in your application context. For =
services outside of the application context, you could assign the =
validator bean manually by getting a reference to the application =
context, looking up the bean, and setting it to your service instance. =
All of this would work in a standalone application too, if it utilizes a =
Spring application Context.=20

Therefore, I don't see a need for validator plug-ins or the like. This =
demonstrates the power of the bean factory concept: You can achieve so =
much with it so easily.

BTW, I assume that the unfinished class in Spring's validation package =
that you mentioned is ValidationUtils. This class is meant to be a =
simple static utility class that provides low-level validation checks to =
ease Validator implementations. Don't confuse this with your Validator =
implementations and their reusability across multiple layers.

Regards,
Juergen

RE: [Springframework-developer] purpose of code in Errors.rejectValue()

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

Hi Tony,

Regarding your proposed changes to the Errors interface:

> Right now, I believe the API to obtaining messages for=20
> anything in the framework is limited in 2 ways:
> 1)  Does not allow parameters to be passed to it.
> 2)  Some of the APIs do not allow a Locale to be passed into them (the
> Errors.rejectValue(...) is a good example.
>=20
> My changes should address both these issues.  Also, I am=20
> attempting to add a subclass to the NestedException class=20
> (that merely calls a helper
> object) that will allow Exceptions themselves to obtain their=20
> messages from a ResourceBundle.

> rejectValue(String field, String errorCode, String message)
> rejectValue(String field, Locale locale, String errorCode, Object[] =
errorArgs, String defaultMessage)

You're right concerning the opportunity for message arguments. But I'm =
not sure about resolving the message from some specific error messages =
file, completely separated from the ApplicationContext and its =
MessageSource. Tbis would be inconsistent with the rest of Spring's =
message handling.

What do you intend to achieve with the Locale parameter to rejectValue? =
Do you intend to resolve the message immediately? This is not what =
localized messages is about. You need to resolve the message with the =
display locale, i.e. the locale of the user that actually sees the =
message.

If you simply want to generate a message including message arguments for =
a single language, then do so in your validation code and give your =
completed String result to the simple rejectValue version. The errorCode =
can be used for a short general identifier instead of a message key, as =
you've pointed out.

If you want to have localized messages with message arguments, then use =
the rejectValue version with errorArgs: The errorCode has to match the =
MessageSource key (i.e. ResourceBundle key in most cases) but simply =
gets stored, and so do the errorArgs. The final message gets constructed =
by the user of the Errors instance, e.g. the BindTag instance that =
prepares the Errors state for web UI usage via BindStatus. So the =
rejectValue implementation must not try to construct the final message, =
as it is not and should not be aware of the current user's Locale.

Therefore, the signatures should rather look as follows (note: no Locale =
parameter):
- rejectValue(String field, String errorCode, String message)
- rejectValue(String field, String errorCode, Object[] errorArgs, String =
defaultMessage)

Finally, how do you intend to merge the message from the resource bundle =
with the error arguments? Keep in mind that this should not happen in =
the rejectValue implementation! Taking BindTag as example again: =
Currently it simply tries to resolve the errorCode and the given message =
via the ApplicationContext's MessageSource support. How do you intend to =
make this work with error arguments? Wouldn't this mean extending =
MessageSource with overloaded getMessage versions that feature an =
errorArgs parameter?

Let's discuss this issue before you get your stuff into CVS, for =
clarity's sake. I've also made some changes to the Errors approach (as =
you're probably aware), especially for usage by the web package, so we =
should definitely synchronize our efforts!

Regards,
Juergen

RE: [Springframework-developer] purpose of code in Errors.rejectV alue()

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

Tony,


Thanks for your explanation. It makes a lot more sense now.

 

To be honest, I'm not as familar with the Validator pattern.  
From my recollection of that chapter in the book, I thought
Rod advocated having a separate object that contained all validation logic
that both
the Business Object layer, and the Controller could call.  Better to have
Rod
field that question.

[John Cavacas] That was my understanding as well in regards to the validator
interface from reading the book. But unless I missed something obvious, I
just don't see how that would work, especially from the Business Object
layer side of things. I've been playing around with some ideas as well to
come up with a way to have common "validator plug-ins". I saw a class in
spring that I think is ment for that purpose, but it looks like an
unfinished thought. I think that using the bean framework and maybe a change
in the validator interface, could make that concept a reality, and it's
something that I want to explore.

Thanks again,
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] purpose of code in Errors.rejectV alue()

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

John, 
Here's my understanding of how it currently works.  
Let's consider a normal Java Exception.  To create an exception that
has text associated with it you must create the exception instance using the
Exception(String s) constructor.  As an example let's assume we create
an exception that contains the message "Unable to communicate with the Credit Processing System at this time.".
It is often helpful for errors that are to be displayed to the user to also contain
an errorCode.  In the mainframe world, an errorCode like "22" would usually be associated 
with this msg.  The framework allows for such an errorCode, only it's more flexible since it
is a string.  Thus for our errorCode we might choose something like "CreditSysDown".
This errorCode need not ever be shown to the user (though in some cases it can be helpful) 
but some of the advantages it provides are:
1) Quite often the same Exception class is used for various exceptions (ie: SystemDownException)
   but with various messages for each exception.  Having an errorCode associated
   with the message would allow you to perhaps setup a mapping table to know 
   what field on the screen might need to be turned to red.  
   
   Consider a fat client GUI that shows a graphical status of all systems it monitors.
   If a system is down it changes that icon red (it's not the best example, as you could argue
   why not just ping that system - but in calls to mainframes you might have
   to wait for a JMS call to throw an exception to know if that system is down).
   In such an example the exception might be a SystemDownException, but the errorCode
   might be "CreditSysDown", "MortgageSysDown", etc.  The mapping table might be driven
   off of these codes then.
2) With an errorCode associated to a message, you can use the errorCode as a key
   to resolving the actual msg from within an external file.  This allows for
   internationalization since the msg will be resolved using a ResourceBundle, 
   and it also keeps all your messages in a single place.  (An added benefit of this
   is that no longer do you need to change the text of the exception in multiple 
   places throughout your code if you decide you don't like the text being shown for a 
   message.  If you aren't familiar with ResourceBundles, please see Struts docs for 
   examples of errorKeys contained in text files.
As it stands the Errors object is limited in 2 ways:  that it cannot resolve msgs from a file,
and it doesn't allow you to pass in args that need to be replaced in a msg.  This 
will be part of the code I am soon to put into CVS.  I do not have the code with me at
the minute, but off the top of my head I believe these are some of the method
signatures it will have:
 rejectValue(String field,String errorCode, String message) - NOT resolving from a file (literally take the msg I am passing in)
 rejectValue(String field, Locale locale, String errorCode, Object[] errorArgs, String defaultMessage) - TO resolve the errorCode to a message contained within a file

To be honest, I'm not as familar with the Validator pattern.  
From my recollection of that chapter in the book, I thought
Rod advocated having a separate object that contained all validation logic that both
the Business Object layer, and the Controller could call.  Better to have Rod
field that question.
 
 John Cavacas <joh...@sa...> wrote:Tony,

Thanks for the reply.

That was my guess as well about the code property. But it also leads to
another question.

The method signature is also includes the "message" parameter. So that is
point of having both "code" and "message" if the "code" would contain the
message? Do I perhaps not understand the intended use?

In my tests the functionality seems to be working as expected (not including
the codes as I'm not currently using them). I'm using the BindException
implementation class to hold the errors for my domain object validator.

My original idea was to use this validator to perform syntactic and semantic
validation, but I've quickly realized that the only way this validator can
do that is if it has access to the business object, which in my opinion it
can't or shouldn't have. It seems that the validator interface is really
more suited for syntactic validation to occour for example before the object
is sent to the business method. The only way that I can think of making that
work is if somehow the validator object and the business object had access
to the same Errors object. To be more specific...

My validator object can check for example to see if an email address looks
like it is properly formatted. However I also need to know if this
particular email message already exists in my database because my business
rule dictates that there cannot be duplicate email addresses. In order for
the validator object to know that, it would have to ask the business object
to perform that look up, which in my opinion doesn't seem right.

So my current solution is to perform the syntactic validation on the
validator, pass the domain object (a command) to the business method, and
let the business method perform the business rules, which in case of
problems would be expressed as typed exceptions. Does this make sense? Or is
there a way to actually make the validator perform both functions?

Thanks,
John



> -----Original Message-----
> From: Tony Falabella [mailto:ton...@ya...]
> Sent: Monday, March 03, 2003 8:58 PM
> To: joh...@sa...; spr...@li...
> Subject: RE: [Springframework-developer] purpose of code in
> Errors.rejectValue()
> 
> John,
> 
> I believe the "code" field refers to an "ErrorCode" that could be used
> as a string value of an error msg that is associated with that Error.
> (Similar to a mainframe returning an error code when a bad message is
> returned to a user, only since it's a string it can actually be a bit
> descriptive for the user.) See the javadocs for the
> com.interface21.core.ErrorCoded interface for a detailed description.
> 
> I am making some changes to the framework (then will pend review from
> Rod) to allowing ResourceBundles to be tied into a few things within the
> framework a little better.
> 
> Right now, I believe the API to obtaining messages for anything in the
> framework is limited in 2 ways:
> 1) Does not allow parameters to be passed to it.
> 2) Some of the APIs do not allow a Locale to be passed into them (the
> Errors.rejectValue(...) is a good example.
> 
> My changes should address both these issues. Also, I am attempting to
> add a subclass to the NestedException class (that merely calls a helper
> object) that will allow Exceptions themselves to obtain their messages
> from a ResourceBundle. I have this working now for myself, but wish to
> make a few changes to it to model the behavior of how log4j allows you
> to point various classes to various files (ie: Exceptions in this
> package look to this file for their msgs). I am a few days away from a
> code review on this.
> 
> As far as answering your question about examples, I'm sorry but I don't
> have any examples to give you.
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of John Cavacas
> Sent: Monday, March 03, 2003 4:03 PM
> To: spr...@li...
> Subject: [Springframework-developer] purpose of code in
> Errors.rejectValue()
> 
> I was wondering if someone, most likelly Rob, could tell me what the
> purpose of the String code parameter is in Errors.rejectValue(String
> field,String code,String message) method.
> 
> And like my previous email "Validation usage examples and questions" i
> am looking for further clarification and proposed usage of the
> validation and DataBinding techniques in the framework.
> 
> Thanks,
> John
> 
> 
> 
> -------------------------------------------------------
> 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. (c) 2002
Sapiens Americas Corp.

[Springframework-developer] purpose of code in Errors.rejectValue ()

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

Now I know what Rod was complaining about... in regards that the reply goes
back to the user, not the list.. there must be a way to fix that.



> -----Original Message-----
> From: John Cavacas
> Sent: Tuesday, March 04, 2003 12:27 PM
> To: 'Tony Falabella'
> Subject: RE: [Springframework-developer] purpose of code in
> Errors.rejectValue()
> 
> Tony,
> 
> Thanks for the reply.
> 
> That was my guess as well about the code property. But it also leads to
> another question.
> 
> The method signature is also includes the "message" parameter. So that is
> point of having both "code" and "message" if the "code" would contain the
> message? Do I perhaps not understand the intended use?
> 
> In my tests the functionality seems to be working as expected (not
> including the codes as I'm not currently using them). I'm using the
> BindException implementation class to hold the errors for my domain object
> validator.
> 
> My original idea was to use this validator to perform syntactic and
> semantic validation, but I've quickly realized that the only way this
> validator can do that is if it has access to the business object, which in
> my opinion it can't or shouldn't have. It seems that the validator
> interface is really more suited for syntactic validation to occour for
> example before the object is sent to the business method. The only way
> that I can think of making that work is if somehow the validator object
> and the business object had access to the same Errors object. To be more
> specific...
> 
> My validator object can check for example to see if an email address looks
> like it is properly formatted. However I also need to know if this
> particular email message already exists in my database because my business
> rule dictates that there cannot be duplicate email addresses. In order for
> the validator object to know that, it would have to ask the business
> object to perform that look up, which in my opinion doesn't seem right.
> 
> So my current solution is to perform the syntactic validation on the
> validator, pass the domain object (a command) to the business method, and
> let the business method perform the business rules, which in case of
> problems would be expressed as typed exceptions. Does this make sense? Or
> is there a way to actually make the validator perform both functions?
> 
> Thanks,
> John
> 
> 
> 
> > -----Original Message-----
> > From: Tony Falabella [mailto:ton...@ya...]
> > Sent: Monday, March 03, 2003 8:58 PM
> > To: joh...@sa...; springframework-
> dev...@li...
> > Subject: RE: [Springframework-developer] purpose of code in
> > Errors.rejectValue()
> >
> > John,
> >
> > I believe the "code" field refers to an "ErrorCode" that could be used
> > as a string value of an error msg that is associated with that Error.
> > (Similar to a mainframe returning an error code when a bad message is
> > returned to a user, only since it's a string it can actually be a bit
> > descriptive for the user.)  See the javadocs for the
> > com.interface21.core.ErrorCoded interface for a detailed description.
> >
> > I am making some changes to the framework (then will pend review from
> > Rod) to allowing ResourceBundles to be tied into a few things within the
> > framework a little better.
> >
> > Right now, I believe the API to obtaining messages for anything in the
> > framework is limited in 2 ways:
> > 1)  Does not allow parameters to be passed to it.
> > 2)  Some of the APIs do not allow a Locale to be passed into them (the
> > Errors.rejectValue(...) is a good example.
> >
> > My changes should address both these issues.  Also, I am attempting to
> > add a subclass to the NestedException class (that merely calls a helper
> > object) that will allow Exceptions themselves to obtain their messages
> > from a ResourceBundle.  I have this working now for myself, but wish to
> > make a few changes to it to model the behavior of how log4j allows you
> > to point various classes to various files (ie: Exceptions in this
> > package look to this file for their msgs).  I am a few days away from a
> > code review on this.
> >
> > As far as answering your question about examples, I'm sorry but I don't
> > have any examples to give you.
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf
> > Of John Cavacas
> > Sent: Monday, March 03, 2003 4:03 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] purpose of code in
> > Errors.rejectValue()
> >
> > I was wondering if someone, most likelly Rob, could tell me what the
> > purpose of the String code parameter is in Errors.rejectValue(String
> > field,String code,String message) method.
> >
> > And like my previous email "Validation usage examples and questions" i
> > am looking for further clarification and proposed usage of the
> > validation and DataBinding techniques in the framework.
> >
> > Thanks,
> > John
> >
> >
> >
> > -------------------------------------------------------
> > 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. (c) 2002
Sapiens Americas Corp.

RE: [Springframework-developer] Help!!!

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

Gentlemen,

thanks. I'll check that theory.

Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: Tuesday, March 04, 2003 12:31 PM
To: Spring Developers (E-mail)
Subject: RE: [Springframework-developer] Help!!!


Yep, the classloader hierarchy should be the cause. I guess that OC4J =
has
its own version of Log4J 1.1.x in the common classpath, combined with
sticking to the standard J2SE classloader hierarchy that prioritizes =
base
libraries - a big no-no for a "friendly" container.

The Servlet spec encourages a classloader hierarchy that prioritizes =
the web
app's classloader. Such a problem cannot occur then if you include all =
your
libraries in WEB-INF/lib. This is Tomcat 4's default behavior, and at =
least
configurable in other containers, e.g. Resin.

So OC4J should offer a configuration setting for the Servlet spec
classloader hierarchy, but I don't actually know. Consult your
documentation... ;-) Another but less preferable solution would be to
exchange OC4J's common Log4J 1.1 JAR with a newer Log4J 1.2 JAR - it =
should
be backward compatible.

Juergen


> -----Original Message-----
> From: William G. Thompson, Jr. [mailto:wg...@rc...]=20
> Sent: Tuesday, March 04, 2003 6:22 PM
> To: Kopylenko, Dmitry
> Cc: 'spring-dev-list'
> Subject: Re: [Springframework-developer] Help!!!
>=20
>=20
> Looks like your picking up a different version of log4j=20
> somehow.  You'll=20
> have to understand how the classloader works in OC4J and check your=20
> classpath.
>=20
> Bill
>=20
>=20
> Kopylenko, Dmitry wrote:
> > Gentlemen,
> >=20
> > I'm having trouble deploying simple Spring-enabled web-app=20
> to Oracle's=20
> > OC4J. The problem is with log4j. It works fine in the local copy of =

> > JBoss. When I try to deploy it on OC4J I get the following:
> >=20
> > 500 Internal Server Error
> > java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: =

> > <clinit>
> > signature: ()V) Incompatible argument to function
> > 	at org.apache.log4j.Logger.getLogger(Logger.java:85)
> > 	at
> >=20
> com.interface21.web.servlet.HttpServletBean.<init>(HttpServlet
> Bean.java:49)
> > 	at
> >=20
> com.interface21.web.servlet.FrameworkServlet.<init>(FrameworkS
> ervlet.java:47
> > )
> > 	at
> >=20
> com.interface21.web.servlet.ControllerServlet.<init>(Controlle
> rServlet.java:
> > 69)
> > 	at java.lang.Class.newInstance0(Native Method)
> > 	at java.lang.Class.newInstance(Class.java:232)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpApplication.loadServlet(HttpApplication.
> java:1645)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpApplication.findServlet(HttpApplication.
> java:4006)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpApplication.getDefaultDispatcher(HttpApp
> lication.java:
> > 2559)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpApplication.getRequestDispatcher(HttpApp
> lication.java:
> > 2308)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpRequestHandler.processRequest(HttpReques
> tHandler.java:
> > 585)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:243)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> > J2EE].util.ThreadPoolThread.run(ThreadPoolThread.java:64)
> >=20
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++
> > ++++++++++++++++++++++++++++++++++++++++++++++
> >=20
> > I am stuck. Any ideas would be appreciated.
> >=20
> > Thanks.
> >=20
> > Dmitriy.
> >=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of=20
> TotalView, The debugger=20
> for complex code. Debugging C/C++ programs can leave you=20
> feeling lost and=20
> disoriented. TotalView can help you find your way. Available=20
> on major UNIX=20
> and Linux platforms. Try it free. www.etnus.com=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20


-------------------------------------------------------
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] Help!!!

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

Yep, the classloader hierarchy should be the cause. I guess that OC4J =
has its own version of Log4J 1.1.x in the common classpath, combined =
with sticking to the standard J2SE classloader hierarchy that =
prioritizes base libraries - a big no-no for a "friendly" container.

The Servlet spec encourages a classloader hierarchy that prioritizes the =
web app's classloader. Such a problem cannot occur then if you include =
all your libraries in WEB-INF/lib. This is Tomcat 4's default behavior, =
and at least configurable in other containers, e.g. Resin.

So OC4J should offer a configuration setting for the Servlet spec =
classloader hierarchy, but I don't actually know. Consult your =
documentation... ;-) Another but less preferable solution would be to =
exchange OC4J's common Log4J 1.1 JAR with a newer Log4J 1.2 JAR - it =
should be backward compatible.

Juergen


> -----Original Message-----
> From: William G. Thompson, Jr. [mailto:wg...@rc...]=20
> Sent: Tuesday, March 04, 2003 6:22 PM
> To: Kopylenko, Dmitry
> Cc: 'spring-dev-list'
> Subject: Re: [Springframework-developer] Help!!!
>=20
>=20
> Looks like your picking up a different version of log4j=20
> somehow.  You'll=20
> have to understand how the classloader works in OC4J and check your=20
> classpath.
>=20
> Bill
>=20
>=20
> Kopylenko, Dmitry wrote:
> > Gentlemen,
> >=20
> > I'm having trouble deploying simple Spring-enabled web-app=20
> to Oracle's=20
> > OC4J. The problem is with log4j. It works fine in the local copy of=20
> > JBoss. When I try to deploy it on OC4J I get the following:
> >=20
> > 500 Internal Server Error
> > java.lang.VerifyError: (class: org/apache/log4j/LogManager, method:=20
> > <clinit>
> > signature: ()V) Incompatible argument to function
> > 	at org.apache.log4j.Logger.getLogger(Logger.java:85)
> > 	at
> >=20
> com.interface21.web.servlet.HttpServletBean.<init>(HttpServlet
> Bean.java:49)
> > 	at
> >=20
> com.interface21.web.servlet.FrameworkServlet.<init>(FrameworkS
> ervlet.java:47
> > )
> > 	at
> >=20
> com.interface21.web.servlet.ControllerServlet.<init>(Controlle
> rServlet.java:
> > 69)
> > 	at java.lang.Class.newInstance0(Native Method)
> > 	at java.lang.Class.newInstance(Class.java:232)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpApplication.loadServlet(HttpApplication.
> java:1645)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpApplication.findServlet(HttpApplication.
> java:4006)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpApplication.getDefaultDispatcher(HttpApp
> lication.java:
> > 2559)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpApplication.getRequestDispatcher(HttpApp
> lication.java:
> > 2308)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpRequestHandler.processRequest(HttpReques
> tHandler.java:
> > 585)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> >=20
> J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:243)
> > 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> > J2EE].util.ThreadPoolThread.run(ThreadPoolThread.java:64)
> >=20
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++
> > ++++++++++++++++++++++++++++++++++++++++++++++
> >=20
> > I am stuck. Any ideas would be appreciated.
> >=20
> > Thanks.
> >=20
> > Dmitriy.
> >=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of=20
> TotalView, The debugger=20
> for complex code. Debugging C/C++ programs can leave you=20
> feeling lost and=20
> disoriented. TotalView can help you find your way. Available=20
> on major UNIX=20
> and Linux platforms. Try it free. www.etnus.com=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

Re: [Springframework-developer] Help!!!

[William G. T. Jr. <wg...@rc...>]

Looks like your picking up a different version of log4j somehow.  You'll 
have to understand how the classloader works in OC4J and check your 
classpath.

Bill


Kopylenko, Dmitry wrote:
> Gentlemen,
> 
> I'm having trouble deploying simple Spring-enabled web-app to Oracle's OC4J.
> The problem is with log4j. It works fine in the local copy of JBoss. When I
> try to deploy it on OC4J I get the following:
> 
> 500 Internal Server Error
> java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: <clinit>
> signature: ()V) Incompatible argument to function
> 	at org.apache.log4j.Logger.getLogger(Logger.java:85)
> 	at
> com.interface21.web.servlet.HttpServletBean.<init>(HttpServletBean.java:49)
> 	at
> com.interface21.web.servlet.FrameworkServlet.<init>(FrameworkServlet.java:47
> )
> 	at
> com.interface21.web.servlet.ControllerServlet.<init>(ControllerServlet.java:
> 69)
> 	at java.lang.Class.newInstance0(Native Method)
> 	at java.lang.Class.newInstance(Class.java:232)
> 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> J2EE].server.http.HttpApplication.loadServlet(HttpApplication.java:1645)
> 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> J2EE].server.http.HttpApplication.findServlet(HttpApplication.java:4006)
> 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> J2EE].server.http.HttpApplication.getDefaultDispatcher(HttpApplication.java:
> 2559)
> 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> J2EE].server.http.HttpApplication.getRequestDispatcher(HttpApplication.java:
> 2308)
> 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:
> 585)
> 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:243)
> 	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
> J2EE].util.ThreadPoolThread.run(ThreadPoolThread.java:64)
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++++++++++++++++++++++++++++++
> 
> I am stuck. Any ideas would be appreciated.
> 
> Thanks.
> 
> Dmitriy.
> 

[Springframework-developer] Help!!!

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

Gentlemen,

I'm having trouble deploying simple Spring-enabled web-app to Oracle's OC4J.
The problem is with log4j. It works fine in the local copy of JBoss. When I
try to deploy it on OC4J I get the following:

500 Internal Server Error
java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: <clinit>
signature: ()V) Incompatible argument to function
	at org.apache.log4j.Logger.getLogger(Logger.java:85)
	at
com.interface21.web.servlet.HttpServletBean.<init>(HttpServletBean.java:49)
	at
com.interface21.web.servlet.FrameworkServlet.<init>(FrameworkServlet.java:47
)
	at
com.interface21.web.servlet.ControllerServlet.<init>(ControllerServlet.java:
69)
	at java.lang.Class.newInstance0(Native Method)
	at java.lang.Class.newInstance(Class.java:232)
	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
J2EE].server.http.HttpApplication.loadServlet(HttpApplication.java:1645)
	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
J2EE].server.http.HttpApplication.findServlet(HttpApplication.java:4006)
	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
J2EE].server.http.HttpApplication.getDefaultDispatcher(HttpApplication.java:
2559)
	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
J2EE].server.http.HttpApplication.getRequestDispatcher(HttpApplication.java:
2308)
	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:
585)
	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:243)
	at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for
J2EE].util.ThreadPoolThread.run(ThreadPoolThread.java:64)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++

I am stuck. Any ideas would be appreciated.

Thanks.

Dmitriy.

Re: [Springframework-developer] com.interface21.web.servlet subpackages

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

Moving handler mapping implementations is fine by me.

Rod

[Springframework-developer] com.interface21.web.servlet subpackages

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

Would anybody mind if I moved UrlHandlerMapping and =
BeanNameUrlHandlerMapping to a new subpackage =
com.interface21.web.servlet.handler, leaving just the HandlerMapping =
interface in the com.interface21.web.servlet package itself?

This would make the separation analogous to the View interface being in =
com.interface21.web.servlet, and concrete View implementations residing =
in com.interface21.web.servlet.view. LocaleResolver and the i18n =
subpackage work the same way too.

I consider this a consequent move, to be performed as early as possible =
due to UrlHandlerMapping's importance. Any objections?

BTW, I'm currently finishing HTML escaping support for Spring, both via =
utility methods and via the tags, combined with refactored support for =
JSP scriptlets and Velocity templates in the form of a new =
RequestContext class. And there were still some inconsistencies in =
locale handling that I've fixed in the meantime. I hope to get that =
stuff into CVS soon.

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

[Springframework-developer] Spring's web support vs Struts

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

Hi everybody,

I've recently browsed through the thread "Struts design flaw -- =
ActionForms are not true domain objects" on the Struts mailing list. =
Obviously, some people treat that as a religious issue - after all, form =
handling, i.e. the design of the ActionForm class, is a central aspect =
of Struts. Interestingly, Rod's book is explictly mentioned and =
discussed.

There seem to some real fans of Struts' design, e.g. =
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=3D42&msgNo=3D64642:
"Now does it break this book's opinion of proper design patterns? I'm =
sure it does, but what GREAT engineers don't break design pattern rules =
when it benefits the end result of an application or framework? Patters =
are there to solve issues we have, not to stick us into lala land with =
shackles and whips telling us that we must do it that way. They're =
merely there to help us write better OO design, and from where I sit the =
Struts design is as close to perfect as you can get right now=20
for WEB-based development."

An interesting and quite offensive posting is the following one, from =
Peter Pilgrim, dedicated "Struts Consultant" (who also wrote some =
Expresso article for TheServerSide, IIRC):
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=3D42&msgNo=3D65119. He =
virtually dismisses Rod's views on Struts' flaws in the twinkling of an =
eye. Now that's what I call open discussion...

So everybody seems to love writing ActionForms and copying the =
properties to the respective domain objects on submit, using Commons =
BeanUtils. I don't consider this elegant, but I respect their views too. =
I simply believe that there is a better way.

I consider the ubiquitousness of ActionForms an even greater design flaw =
of Struts. Struts' Action API only knows one single execute/perform =
signature, with ActionMapping, ActionForm, HttpServletRequest, and =
HttpServletResponse. This is inflexible and inelegant. Of course, the =
form may be null, according to your action mapping declaration. =
Generally, why do I have to declare form beans in a descriptor? And =
ActionMapping is basically just needed for resolving symbolic view =
names. All things considered, the Action/ActionMapping approach is at =
least as flawed as the ActionForm class.

Of course, anybody is free to choose and even like Struts' approach. =
BTW, what's the status of our proposed Struts plugin? I really like that =
idea because it gives the application developer choices. After all, =
Spring is more than "just" a web framework, and deserves to get used in =
a wide variety of scenarios. It offers such appropriate generic =
infrastructure for the middle tier, with nice integration with but clear =
separation from the web support on top of it.

Anyway, IMHO Spring's way of web MVC is so much cleaner and so much more =
sophisticated than Struts'. Consider the choice between Controller, =
CommandController, and FormController, or the flexibility of =
HandlerMapping and ViewResolver. Due to the latter interfaces, you don't =
need to explictly map something in a config file that you don't want to =
- simply use an implicit mapping strategy like BeanNameUrlHandlerMapping =
or InternalResourceViewResolver, or implement your own. And we haven't =
even talked about validation, or retrieval and configuration of business =
logic services yet.

In the end, I guess I'm simply a fan... ;-)

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
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG