Sean, i also noted that Shale only register one Variable/Property resolver, if i have more than one Variable/Property Resolver packaged in different jars only the first found is registered, this is correct?
2006/7/24, Butash, Bob <[EMAIL PROTECTED]>:
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. 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. We are really only leveraging the View Controller logic at this time. 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. Thanks -----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 > > > > >
-- Yours truly (Atenciosamente), Rogério
