springframework-developer — Spring Framework developers list

[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

[Springframework-developer] Where to start with Spring framework?

[Davor C. <dav...@ma...>]

I heard of Spring Framework on the Struts mailing list. So far I know that 
it should be a J2EE application framework which solves many Struts's (and 
some other frameworks') problems.

I've been reading this mailing list for the last two-three weeks and I'm 
interested in joining the development team (I have at least 15hrs/week of 
the 'developers time' for the next 2 months). I fetched the CVS 
sourcetree but I don't understand quite clearly where to start. 
Unfortunatelly, I don't have the book either (Amazon ships it within 3-5 
weeks and my local bookstore sold it out).

So the question is: is there some sample application or quickstart document 
or do I really need to read the book? Since I won't get my copy of the book 
for at least 5 weeks from now, how can I start with Spring? Are there some 
book excerpts available, which cover the framework's basics?

And when I'm already writing this, some remarks regarding recent 
discussions:

- you really need some 0.8 prerelease or something like that, just to help 
the people (like myself) to start. With early release you'll get the 
momentum, lots of bug fixes, suggestions etc (standard open source 
artifacts)
- jalopy is a really good tool, on my last job I forced the development 
team to use it (we used WSAD as well) and it really helped with 
readability. We were most satisfied with the members sorting and long 
statement splitting:

DbConnector.getConnection()
           .fetchResultSet()
           .toXml()
           .save()

I have a quite nice jalopy config file if you're interested in it, I could 
post it somewhere.

Regards,
Davor
-- 
dav...@ma...

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

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

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

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

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

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

Re: [Springframework-developer] Code format tools Part II

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

> I am personally not accustomed to having an external automated tool
> exert so much control over my code.  However, if the group or Rod feels
> that the above requirements need to be enforced programatically for the
> health of the project, I could be convinced.

I'm waiting to see what Tony comes up with, so I can try it before I buy it.

I'm not accustomed to this either, but I think there are some real
advantages, especially wrt CVS.

I think a lot of other projects just have inconsistency, which I don't like.

Rod

Re: [Springframework-developer] Code format tools Part II

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

First, +1 on not introducing dependencies on a/any IDE.
(eclipse today...back to vi tomorrow ;)  Long Live Ant!

Tony Falabella wrote:
> I see your point now. 
> 
> Actually it is not enough for us to set up the format template to just 
> perform indentation, we will have to have it sort methods/attributes at 
> least by name, and by modifier (according to recommendation in the book). 
> 
> This should then accomplish what we need.

I am personally not accustomed to having an external automated tool 
exert so much control over my code.  However, if the group or Rod feels 
that the above requirements need to be enforced programatically for the 
health of the project, I could be convinced.

> 
> I can't comment on whether or not Eclipse settings would also do the 
> same thing, but I don't think we should require all developers to use 
> Eclipse (and if everyone does not do the same thing consistently there's 
> no point in doing any of this).

The consistency issue is really my main point, and I'm concerned that 
even having an automated tool will not mitigate this risk.  (are other 
open source projects doing this?)

It seems reasonable enough to set some guidelines, enforce them by group 
dynamics, and leave code consistent to the way you found it.

This is simple and ease to implement.

Bill

> 
> If our format template includes sorting, do you concur that it should 
> address our needs?
>   
> 
>  "William G. Thompson, Jr." <wg...@rc... 
> <mailto:wg...@rc...>> wrote:
> 
> Tony Falabella wrote:
>  > Bill,
>  >
>  > I believe the main point of the exercise is to easily see diffs in
>  > changes in the repos. As such, I believe issue #2 has to be ruled out
>  > (please read on).
> 
> The issues with diffs is exactly why #2 is important. In other words,
> unless the the automated mechanism can be garunteed to only munge code
> changed by a developer, diffs will get corrupted. I have not used
> Jalopy, so I can not comment on its consistency.
> 
> The diff problem is easily solved if #2 is our mode of operation. The
> goodliness of the code formating can be solved simply with the correct
> eclipse settings. This does not rule out the one-time reformating of
> the code base.
> 
> Bill
> 
>  > My thoughts are I will check out ALL code the first time, run it through
>  > the formatter with an agreed upon template and check it back in
>  > (comments for checkin will be something like "reformatted to group
>  > standard format").
>  >
>  > After that, the requirement on developers will simply be to make sure
>  > you run the Ant build/tests RIGHT BEFORE checking in your code (a
>  > procedure all should be following anyway). This will ensure it is in
>  > the format that the group agreed upon when you perform your checkin (FYI
>  > - only classes you have as writable will be effected).
>  >
>  > There is no mandate that any developer use the beautifier themselves.
>  > If you so choose to use a beautifier yourself, you can pick any
>  > beautifier you'd like, and create any format you like. Your changes
>  > will not be seen by the group though since the Ant script will reformat
>  > the code to the group's agreed upon format prior t you checking that
>  > code in.
>  >
>  > In case you wish to use Jalopy yourself within an IDE I will tell the
>  > group where the format file is located (and this is specific to
>  > Jalopy). You will then just need to point Jalopy to this file.
>  >
>  >
> 
>  
> 


-- 
William G. Thompson, Jr.
Associate Director of New Technologies
Administrative Computing Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wth...@ac...

Re: [Springframework-developer] Code format tools Part II

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

Much as I love Eclipse, I think it's important that our build/commit process
is purely handled by Ant. I don't like forcing people to use a particular
IDE (or _any_ IDE, for that matter).

Also, Juergen Hoeller is one active contributor who's not using Eclipse.
(IDEA).

----- Original Message -----
From: "Tony Falabella" <ton...@ya...>
To: "William G. Thompson, Jr." <wg...@rc...>
Cc: <spr...@li...>
Sent: Monday, March 03, 2003 4:33 PM
Subject: Re: [Springframework-developer] Code format tools Part II


>
> I see your point now.  Actually it is not enough for us to set up the
format template to just perform indentation, we will have to have it sort
methods/attributes at least by name, and by modifier (according to
recommendation in the book).
> This should then accomplish what we need.
> I can't comment on whether or not Eclipse settings would also do the same
thing, but I don't think we should require all developers to use Eclipse
(and if everyone does do the same thing consistently there's no point in
doing any of this).
> If our format template includes sorting, do you concur that it should
address our needs?
>
>  "William G. Thompson, Jr." <wg...@rc...> wrote:Tony Falabella
wrote:
> > Bill,
> >
> > I believe the main point of the exercise is to easily see diffs in
> > changes in the repos. As such, I believe issue #2 has to be ruled out
> > (please read on).
>
> The issues with diffs is exactly why #2 is important. In other words,
> unless the the automated mechanism can be garunteed to only munge code
> changed by a developer, diffs will get corrupted. I have not used
> Jalopy, so I can not comment on its consistency.
>
> The diff problem is easily solved if #2 is our mode of operation. The
> goodliness of the code formating can be solved simply with the correct
> eclipse settings. This does not rule out the one-time reformating of
> the code base.
>
> Bill
>
> > My thoughts are I will check out ALL code the first time, run it through
> > the formatter with an agreed upon template and check it back in
> > (comments for checkin will be something like "reformatted to group
> > standard format").
> >
> > After that, the requirement on developers will simply be to make sure
> > you run the Ant build/tests RIGHT BEFORE checking in your code (a
> > procedure all should be following anyway). This will ensure it is in
> > the format that the group agreed upon when you perform your checkin (FYI
> > - only classes you have as writable will be effected).
> >
> > There is no mandate that any developer use the beautifier themselves.
> > If you so choose to use a beautifier yourself, you can pick any
> > beautifier you'd like, and create any format you like. Your changes
> > will not be seen by the group though since the Ant script will reformat
> > the code to the group's agreed upon format prior to you checking that
> > code in.
> >
> > In case you wish to use Jalopy yourself within an IDE I will tell the
> > group where the format file is located (and this is specific to
> > Jalopy). You will then just need to point Jalopy to this file.
> >
> >
> >
> > */"William G. Thompson, Jr." /* wrote:
> >
> > William G. Thompson, Jr. wrote:
> > > Tony Falabella wrote:
> > >
> > >> BTW - I've tried to put hooks into CVS to have it run a program
> > (using
> > >> a filter like *.java) prior to commits to it. While the hook
> > appears
> > >> to be there (and you'll see mention of being able to do this in the
> > >> documentation for CVS), the code within CVS has actually been
> > >> commented out. What will happen is you'll get an error like
> > >> "Unimplemented in this version of CVS, consult the reference guide."
> > >> Apparently they added this functionality to CVS, found it was too
> > >> buggy for some platforms/files/etc. so rather than take it out they
> > >> just now return that msg above. Someone has a workaround for it,
> > but
> > >> it doesn't seem recommended. Thus my ANT suggestion.
> > >>
> > >
> > > Folks,
> > >
> > > some suggestions:
> > > 1 agree on source formating and post the eclipse settings
> > > 2) agree to _not_ reformat other ppls code just for the sake of
> > > reformatting
> > > 3) let social mechanisms or our benefical dictator take care of
> > source
> > > formating issues
> > I really mean let social mechanisms or our beneficial dictator take
> > care
> > of enforcement. (as opposed to some software imposed mechanism that
> > will
> > complicate the process)
> >
> > > 4) keep it simple ;)
> > >
> > > Cheers,
> > > Bill
> > >
> >
>
>

Re: [Springframework-developer] Code format tools Part II

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

I see your point now.  

Actually it is not enough for us to set up the format template to just perform indentation, we will have to have it sort methods/attributes at least by name, and by modifier (according to recommendation in the book).  

This should then accomplish what we need. 

I can't comment on whether or not Eclipse settings would also do the same thing, but I don't think we should require all developers to use Eclipse (and if everyone does not do the same thing consistently there's no point in doing any of this). 

If our format template includes sorting, do you concur that it should address our needs? 

 

 


 "William G. Thompson, Jr." <wg...@rc...> wrote: 

Tony Falabella wrote:
> Bill,
> 
> I believe the main point of the exercise is to easily see diffs in 
> changes in the repos. As such, I believe issue #2 has to be ruled out 
> (please read on). 

The issues with diffs is exactly why #2 is important. In other words, 
unless the the automated mechanism can be garunteed to only munge code 
changed by a developer, diffs will get corrupted. I have not used 
Jalopy, so I can not comment on its consistency.

The diff problem is easily solved if #2 is our mode of operation. The 
goodliness of the code formating can be solved simply with the correct 
eclipse settings. This does not rule out the one-time reformating of 
the code base.

Bill

> My thoughts are I will check out ALL code the first time, run it through 
> the formatter with an agreed upon template and check it back in 
> (comments for checkin will be something like "reformatted to group 
> standard format"). 
> 
> After that, the requirement on developers will simply be to make sure 
> you run the Ant build/tests RIGHT BEFORE checking in your code (a 
> procedure all should be following anyway). This will ensure it is in 
> the format that the group agreed upon when you perform your checkin (FYI 
> - only classes you have as writable will be effected).
> 
> There is no mandate that any developer use the beautifier themselves. 
> If you so choose to use a beautifier yourself, you can pick any 
> beautifier you'd like, and create any format you like. Your changes 
> will not be seen by the group though since the Ant script will reformat 
> the code to the group's agreed upon format prior to you checking that 
> code in.
> 
> In case you wish to use Jalopy yourself within an IDE I will tell the 
> group where the format file is located (and this is specific to 
> Jalopy). You will then just need to point Jalopy to this file.
> 
> 


 

Re: [Springframework-developer] Code format tools Part II

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

I see your point now.  Actually it is not enough for us to set up the format template to just perform indentation, we will have to have it sort methods/attributes at least by name, and by modifier (according to recommendation in the book).  
This should then accomplish what we need.
I can't comment on whether or not Eclipse settings would also do the same thing, but I don't think we should require all developers to use Eclipse (and if everyone does do the same thing consistently there's no point in doing any of this).
If our format template includes sorting, do you concur that it should address our needs?
 
 "William G. Thompson, Jr." <wg...@rc...> wrote:Tony Falabella wrote:
> Bill,
> 
> I believe the main point of the exercise is to easily see diffs in 
> changes in the repos. As such, I believe issue #2 has to be ruled out 
> (please read on). 

The issues with diffs is exactly why #2 is important. In other words, 
unless the the automated mechanism can be garunteed to only munge code 
changed by a developer, diffs will get corrupted. I have not used 
Jalopy, so I can not comment on its consistency.

The diff problem is easily solved if #2 is our mode of operation. The 
goodliness of the code formating can be solved simply with the correct 
eclipse settings. This does not rule out the one-time reformating of 
the code base.

Bill

> My thoughts are I will check out ALL code the first time, run it through 
> the formatter with an agreed upon template and check it back in 
> (comments for checkin will be something like "reformatted to group 
> standard format"). 
> 
> After that, the requirement on developers will simply be to make sure 
> you run the Ant build/tests RIGHT BEFORE checking in your code (a 
> procedure all should be following anyway). This will ensure it is in 
> the format that the group agreed upon when you perform your checkin (FYI 
> - only classes you have as writable will be effected).
> 
> There is no mandate that any developer use the beautifier themselves. 
> If you so choose to use a beautifier yourself, you can pick any 
> beautifier you'd like, and create any format you like. Your changes 
> will not be seen by the group though since the Ant script will reformat 
> the code to the group's agreed upon format prior to you checking that 
> code in.
> 
> In case you wish to use Jalopy yourself within an IDE I will tell the 
> group where the format file is located (and this is specific to 
> Jalopy). You will then just need to point Jalopy to this file.
> 
> 
> 
> */"William G. Thompson, Jr." /* wrote:
> 
> William G. Thompson, Jr. wrote:
> > Tony Falabella wrote:
> >
> >> BTW - I've tried to put hooks into CVS to have it run a program
> (using
> >> a filter like *.java) prior to commits to it. While the hook
> appears
> >> to be there (and you'll see mention of being able to do this in the
> >> documentation for CVS), the code within CVS has actually been
> >> commented out. What will happen is you'll get an error like
> >> "Unimplemented in this version of CVS, consult the reference guide."
> >> Apparently they added this functionality to CVS, found it was too
> >> buggy for some platforms/files/etc. so rather than take it out they
> >> just now return that msg above. Someone has a workaround for it,
> but
> >> it doesn't seem recommended. Thus my ANT suggestion.
> >>
> >
> > Folks,
> >
> > some suggestions:
> > 1 agree on source formating and post the eclipse settings
> > 2) agree to _not_ reformat other ppls code just for the sake of
> > reformatting
> > 3) let social mechanisms or our benefical dictator take care of
> source
> > formating issues
> I really mean let social mechanisms or our beneficial dictator take
> care
> of enforcement. (as opposed to some software imposed mechanism that
> will
> complicate the process)
> 
> > 4) keep it simple ;)
> >
> > Cheers,
> > Bill
> >
> 

Re: [Springframework-developer] Code format tools Part II

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

Tony Falabella wrote:
> Bill,
> 
> I believe the main point of the exercise is to easily see diffs in 
> changes in the repos.  As such, I believe issue #2 has to be ruled out 
> (please read on). 

The issues with diffs is exactly why #2 is important.  In other words, 
unless the the automated mechanism can be garunteed to only munge code 
changed by a developer, diffs will get corrupted.  I have not used 
Jalopy, so I can not comment on its consistency.

The diff problem is easily solved if #2 is our mode of operation.  The 
goodliness of the code formating can be solved simply with the correct 
eclipse settings.  This does not rule out the one-time reformating of 
the code base.

Bill

> My thoughts are I will check out ALL code the first time, run it through 
> the formatter with an agreed upon template and check it back in 
> (comments for checkin will be something like "reformatted to group 
> standard format"). 
> 
> After that, the requirement on developers will simply be to make sure 
> you run the Ant build/tests RIGHT BEFORE checking in your code (a 
> procedure all should be following anyway).  This will ensure it is in 
> the format that the group agreed upon when you perform your checkin (FYI 
> - only classes you have as writable will be effected).
> 
> There is no mandate that any developer use the beautifier themselves.  
> If you so choose to use a beautifier yourself, you can pick any 
> beautifier you'd like, and create any format you like.  Your changes 
> will not be seen by the group though since the Ant script will reformat 
> the code to the group's agreed upon format prior to you checking that 
> code in.
> 
> In case you wish to use Jalopy yourself within an IDE I will tell the 
> group where the format file is located (and this is specific to 
> Jalopy).  You will then just need to point Jalopy to this file.
> 
>  
> 
> */"William G. Thompson, Jr." <wg...@rc...>/* wrote:
> 
>     William G. Thompson, Jr. wrote:
>      > Tony Falabella wrote:
>      >
>      >> BTW - I've tried to put hooks into CVS to have it run a program
>     (using
>      >> a filter like *.java) prior to commits to it. While the hook
>     appears
>      >> to be there (and you'll see mention of being able to do this in the
>      >> documentation for CVS), the code within CVS has actually been
>      >> commented out. What will happen is you'll get an error like
>      >> "Unimplemented in this version of CVS, consult the reference guide."
>      >> Apparently they added this functionality to CVS, found it was too
>      >> buggy for some platforms/files/etc. so rather than take it out they
>      >> just now return that msg above. Someone has a workaround for it,
>     but
>      >> it doesn't seem recommended. Thus my ANT suggestion.
>      >>
>      >
>      > Folks,
>      >
>      > some suggestions:
>      > 1 agree on source formating and post the eclipse settings
>      > 2) agree to _not_ reformat other ppls code just for the sake of
>      > reformatting
>      > 3) let social mechanisms or our benefical dictator take care of
>     source
>      > formating issues
>     I really mean let social mechanisms or our beneficial dictator take
>     care
>     of enforcement. (as opposed to some software imposed mechanism that
>     will
>     complicate the process)
> 
>      > 4) keep it simple ;)
>      >
>      > Cheers,
>      > Bill
>      >
> 

Re: [Springframework-developer] Code format tools Part II

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

Bill, 
I believe the main point of the exercise is to easily see diffs in changes in the repos.  As such, I believe issue #2 has to be ruled out (please read on).  
My thoughts are I will check out ALL code the first time, run it through the formatter with an agreed upon template and check it back in (comments for checkin will be something like "reformatted to group standard format").  
After that, the requirement on developers will simply be to make sure you run the Ant build/tests RIGHT BEFORE checking in your code (a procedure all should be following anyway).  This will ensure it is in the format that the group agreed upon when you perform your checkin (FYI - only classes you have as writable will be effected).
There is no mandate that any developer use the beautifier themselves.  If you so choose to use a beautifier yourself, you can pick any beautifier you'd like, and create any format you like.  Your changes will not be seen by the group though since the Ant script will reformat the code to the group's agreed upon format prior to you checking that code in.
In case you wish to use Jalopy yourself within an IDE I will tell the group where the format file is located (and this is specific to Jalopy).  You will then just need to point Jalopy to this file.
 
"William G. Thompson, Jr." <wg...@rc...> wrote:William G. Thompson, Jr. wrote:
> Tony Falabella wrote:
> 
>> BTW - I've tried to put hooks into CVS to have it run a program (using 
>> a filter like *.java) prior to commits to it. While the hook appears 
>> to be there (and you'll see mention of being able to do this in the 
>> documentation for CVS), the code within CVS has actually been 
>> commented out. What will happen is you'll get an error like 
>> "Unimplemented in this version of CVS, consult the reference guide."
>> Apparently they added this functionality to CVS, found it was too 
>> buggy for some platforms/files/etc. so rather than take it out they 
>> just now return that msg above. Someone has a workaround for it, but 
>> it doesn't seem recommended. Thus my ANT suggestion.
>>
> 
> Folks,
> 
> some suggestions:
> 1) agree on source formating and post the eclipse settings
> 2) agree to _not_ reformat other ppls code just for the sake of 
> reformatting
> 3) let social mechanisms or our benefical dictator take care of source 
> formating issues
I really mean let social mechanisms or our beneficial dictator take care 
of enforcement. (as opposed to some software imposed mechanism that will 
complicate the process)

> 4) keep it simple ;)
> 
> Cheers,
> Bill
>