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
possible
- 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.
Don
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
