You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by "Butash, Bob" <bo...@eds.com> on 2006/07/21 16:08:22 UTC
Bundled faces-config.xml
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
Re: Bundled faces-config.xml
Posted by Craig McClanahan <cr...@apache.org>.
On 7/24/06, Rogerio Pereira <ro...@gmail.com> wrote:
>
> 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?
No, all of them are registered ... and the last one registered is the one
that JSF will actually invoke.
You can set up your custom VariableResolver to receive a reference to the
"previous" registered one, by defining a constructor that takes a
VariableResolver as the only parameter. That way, you can provide some
custom processing, but delegate to the previously configured variable
resolver for use cases that you do not handle.
Shale actually has two different custom variable resolvers (one in
shale-spring and one in shale-tiger) that follow this approach. In each
case, the implementation provides something special, and then delegates for
other scenarios.
Craig
2006/7/24, Butash, Bob <bo...@eds.com>:
> >
> > 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:sean.schofield@gmail.com]
> > Sent: Saturday, July 22, 2006 10:19 PM
> > To: user@shale.apache.org
> > 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 <bo...@eds.com> 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
>
>
Re: Bundled faces-config.xml
Posted by Rogerio Pereira <ro...@gmail.com>.
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 <bo...@eds.com>:
>
> 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:sean.schofield@gmail.com]
> Sent: Saturday, July 22, 2006 10:19 PM
> To: user@shale.apache.org
> 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 <bo...@eds.com> 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
RE: Bundled faces-config.xml
Posted by "Butash, Bob" <bo...@eds.com>.
I understand there is a need to for easing the configuration but I
believe you should balance it with how much you are handcuffing people
without their knowledge. Could there be separate distributions for
configurations? This way people that desire everything to be turned on
can simply include a given faces-config or jar file.
In my scenario I do not want to leverage Shale's ActionListener. I do
not have one of my own, I merely want the default ActionListener to be
used, there is no way to accomplish this without having to manually
alter the shale distribution (which I do not like doing) or create
additional custom code(which seems to be defeating the purpose).
Thank you for your thoughts....
-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On Behalf Of Craig
McClanahan
Sent: Monday, July 24, 2006 10:42 AM
To: user@shale.apache.org
Subject: Re: Bundled faces-config.xml
Various comments inline.
On 7/24/06, Butash, Bob <bo...@eds.com> 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:sean.schofield@gmail.com]
> Sent: Saturday, July 22, 2006 10:19 PM
> To: user@shale.apache.org
> 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 <bo...@eds.com> 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
> >
> >
> >
> >
> >
>
Re: Bundled faces-config.xml
Posted by Craig McClanahan <cr...@apache.org>.
Various comments inline.
On 7/24/06, Butash, Bob <bo...@eds.com> 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:sean.schofield@gmail.com]
> Sent: Saturday, July 22, 2006 10:19 PM
> To: user@shale.apache.org
> 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 <bo...@eds.com> 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
> >
> >
> >
> >
> >
>
RE: Bundled faces-config.xml
Posted by "Butash, Bob" <bo...@eds.com>.
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:sean.schofield@gmail.com]
Sent: Saturday, July 22, 2006 10:19 PM
To: user@shale.apache.org
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 <bo...@eds.com> 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
>
>
>
>
>
Re: Bundled faces-config.xml
Posted by Sean Schofield <se...@gmail.com>.
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 <bo...@eds.com> 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
>
>
>
>
>