struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: [s2] Logging levels
Date Mon, 11 Sep 2006 21:08:53 GMT
Make sure you get the latest xwork, as a lot of the changes where in there.

In a nutshell, here is how it works:
 - If the results or interceptors throw any exceptions, fail fast as 
 - Therefore, if a result or interceptor wants to be "optional", meaning 
initialize fine even if its dependencies are missing, then it should do 
so, but complain loudly when it is actually used.

So, it is all up to the specific interceptor/result if it wants to be 
"optional" or not.  The framework takes any exceptions thrown seriously 
and by default, treats everything as required.

Therefore, I modified the JSF stuff to not complain during 
initialization, only during first use.  In the case of Jasper where the 
interceptor class itself might not be available, I think we should 
distribute an "extras"-specific struts-default.xml in the extras jar.  
Now that XWork can load multiple instances of a given file name, we 
should take advantage of it when defining extras components.


Ted Husted wrote:
> I'm bringing this up because we've closed WW-1424 and I'm not sure
> what we did. The referenced commits did a lot of other things, and I
> can't see the trees for the forest.
> With devmode=false, we are emitting 16 INFO lines on startup, mainly
> dealing with partially loaded interceptors and result.
> With devmode=true, we are 58 logging lines on startup, some of which
> seem to be redundant INFO reports regarding partially-loaded
> interceptors and results.
> We are issuign these loggging statements because the default framework
> configuration includes support for interceptors and results that
> include JARs not provided in the framework distribution.
> The thought is that by pre-configuring these members, people who want
> to use features like JSF and JasperReports need only to add the JAR.
> They do not need to take the extra step of adding a configuration
> stanza to their struts.xml. Hence, the framework is simpler for people
> who want to use such things.
> IMHO, true simplicity is elegant. I continue to think
> partially-loading interceptors is an inelegant solution. A truly
> simple solution doesn't make other things harder. In my mind, foisting
> apologetic logging statements on every developer every time we launch
> an application is making everyday life harder.
> The current approach is trying to simulate technology that we don't
> have. If we want drop-and-play plugins, then let's implement the
> technology.
> Until then, let's live with the fact that people who want to use JSF
> or JasperReports will have to add an XML stanza to their configuration
> file, just like we do for Maven plugins.
> But, out-of-the-box, with devmode turned off, we should not issue
> logging statements about conditions that are nominal, when using the
> framework in a default, nothing-added configuration.
> -Ted.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message