Various comments inline. On 7/24/06, Butash, Bob <[EMAIL PROTECTED]> wrote:
The ActionListener that comes with the Shale 1.0.3 snap shot is eating exceptions, where as I have another means to capture and log exceptions.
This eating is pending the completion of a feature already on the roadmap[1] to devise and implement a complete exception strategy. If you have specific thoughts on what kinds of use cases should be supported by this, please comment either on the mailing list or on that issue. If I try to override the ActionListener in my faces-config.xml file,
back to the default, it is ignored in favor of Shale's ActionListener.
It is possible to register more than one action listener, as with all the other implementation overrides. However, the "effective" action listener in use is the one registered in the last faces-config.xml file that is processed. Unfortunately, there is no standard mechanism to control the order in which these files are processed -- so it sounds like the Shale one is getting processed *after* your own inside the webapp. Until the JSF standard lets us control the order of these things, one option would be to programmatically register your own instance in a ServletContextListener or something like that. You need access to the Application instance for this webapp, and can then call setActionListener(). We are really only leveraging the View Controller logic at this time. The implementation of this will require the various registrations that occur in shale-core.jar's configuration file. With the other functionality, although it might not be causing problems,
it is code that is being executed that we are not leveraging, so it is overhead. Also we have seen with other libraries, such as Tomahawk & ADF/Trinidad, that there can be conflicts among component libraries and listeners that are configured. With libraries that offer optional capabilities, I don't think they should be automatically configured. It should be up to the projects that are pulling in these libraries to configure and then use the pieces of the functionality they so chose.
Interesting comment ... one of the most common issues people have had with frameworks like Struts is the fact that you have to explicitly configure a bunch of stuff in web.xml, and the fact that JSF can auto-register things inside a JAR file has been very popular. One option would be to split out shale-core.jar into separate jars for the individual functional areas ... but that would not address the particular issue (exception handling) that is intertwined with the view controller functionality, and is a feature that needs to be finished no matter what. Thanks Craig [1] https://issues.apache.org/struts/browse/SHALE-125 -----Original Message-----
From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Saturday, July 22, 2006 10:19 PM To: [email protected] Subject: Re: Bundled faces-config.xml So what features are you trying to avoid? It sounds like you're talking about the view controller stuff but I can't be sure. I can't think of any problems Shale would cause for you if you used all of the add on stuff in faces-config.xml. For instance, if you don't want the ViewController functionality just don't have any backing beans implement ViewController. Sean On 7/21/06, Butash, Bob <[EMAIL PROTECTED]> wrote: > I have a question regarding the packaging of the faces-config.xml file > with the jar files. It has been our normal practice not to modify or > alter the open source jar files that we include in our application > code, this enables us to easily migrate to new releases of the code. > However with Shale we have noticed the inclusion of the > faces-config.xml file the configures the application with features > that we do not want to leverage at this time. > > We find ourselves having to manually alter the packaged faces-config > so it will not conflict with our configuration. > > I would think that it would be a better practice to provide examples > and documentation as to how to configure an application to use shale > but not to include a faces-config.xml in the standard jar files. My > concern is more with the application and lifecylce elements. > Wondering what others thoughts are on this matter. > > Thanks, > > Bob Butash > > > > >
