You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Heath Borders <he...@gmail.com> on 2004/12/30 15:04:02 UTC
Re: Problems while trying to share myfaces jars among various web applications
I think the FacesConfigurator requires that they be in the WEB-INF/lib
directory, I think putting them anywhere else starts making
assumptions about your web container.
On Thu, 30 Dec 2004 11:05:51 +0100, Alessandro Polverini
<al...@nibbles.it> wrote:
> Hello,
> I'm planning to develop some test applications with myfaces, so I tought
> to put all the jars in the tomcat common/lib directory but that does not
> work. The error I get is:
>
> javax.servlet.ServletException: Undefined component type
> org.apache.myfaces.HtmlPanelLayout
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:125)
> org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:119)
>
> root cause
>
> javax.faces.FacesException: Undefined component type org.apache.myfaces.HtmlPanelLayout
> org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:410)
> org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:244)
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:290)
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:110)
> org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:119)
>
> I tried different combinations and I found that I can put in the shared folders
> everything except myfaces*.jar files: they must be in the WEB-INF/lib directory.
>
> Of course I find it would be better to share them among different applications/contexts
> to ease deployment and management.
>
> Any suggestions?
>
> Thanks,
> Alex
>
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Problems while trying to share myfaces jars among various web
applications
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 30 Dec 2004, Alessandro Polverini wrote:
> On Thu, 2004-12-30 at 08:04 -0600, Heath Borders wrote:
>> I think the FacesConfigurator requires that they be in the WEB-INF/lib
>> directory, I think putting them anywhere else starts making
>> assumptions about your web container.
>
> So if I have 10 (or 100) web applications I need to have 10 (or 100)
> copies of the *same* jars over and over?
>
> That seems a waste of space and resources to me. For example, when a new
> release is out, it's better to upgrade just one set of jars (like I do,
> for example with JSTL), instead of redeploy all the web applications,
> and look for the ones using myfaces.
>
> Is there any way to overcome the problem?
Please see the following pages:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
http://struts.apache.org/userGuide/configuration.html#config_add
While the latter was written for Struts, the same principles apply to
MyFaces.
--
Martin Cooper
> Thanks for the reply,
> Alex
>
>
>
Re: Problems while trying to share myfaces jars among various web
applications
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 30 Dec 2004, Alessandro Polverini wrote:
> On Thu, 2004-12-30 at 08:27 -0600, Heath Borders wrote:
>> The problem is that JSF needs access to the jars in a uniform spot to
>> configure the runtime. The spec says that it should act this way.
>
> I've read and understood the documents Martin Cooper in another mail
> pointed me at (thanks), anyway, this is what I read on the JSF specs,
> paragraph 10.2.5 and 10.2.6:
>
> "These classes and resources comprise the implementation of the JSF APIs
> that is provided by a JSF implementor. Typically, such classes will be
> provided in the form of one or more JAR files, which can be either
> installed with the container s shared class facility, or included in
> the /WEB-INF/lib directory of a web application archive."
>
> So, if I'm not mistaken, the specs explicitly says that those jar can be
> shared among all applications.
>
> That is of course also a golden rule of software distribution: imagine
> if I have N web applications using JSF and a security issue comes out:
> in a shared context I just replace the updated jars while in the other
> case I must manually check all the webapps using them and substitute
> them one by one. Slow and error prone.
It is also a "golden rule" that your web apps should be self-contained.
Otherwise, you have container-specific installation and behaviour, and you
can't just drop your war file into a new container and have it work.
Consider the reverse problem: You find a bug in one of your web apps that
is caused by a problem in a jar that you are sharing across all of your
apps in the same container. You fix the bug in the shared jar. Now you
need to retest *all* of your web apps, to ensure that you didn't break any
of the other ones, since you changed shared code. Slow and error prone.
--
Martin Cooper
>> Probably the best way around this is to see if your servlet container
>> supports aliasing the jars. I'm running websphere, and i think
>> there's a way that I could keep my jars in a common directory, but
>> have my apps all reference them as though they were in their
>> WEB-INF/lilb directories.
>
> That's a nice feature from websphere but I'm stuck with tomcat 5.0.28
> right now: maybe it has something equivalent? I did a quick search but
> without any success.
>
> Best regards,
> Alex
>
>
>
Re: Problems while trying to share myfaces jars among various web applications
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 30 Dec 2004 14:23:44 -0600, Heath Borders
<he...@gmail.com> wrote:
> Well, the problem is that the FacesConfigurator only searches
> WEB-INF/lib and META-INF/services for jars with the faces-config.xml
> file.
>
> Does this mean that during startup, we should try to check every jar
> in the current thread's classloader hierarchy for jars with
> faces-config.xml? That seems like it would take a lot of time.
>
That's one way to do it. The other would be to note that
FacesConfigurator could acquire the knowledge of the class loader *it*
was loaded from (this.getClass().getClassLoader()), and only search
that one -- or, if it's actually a URLClassLoader, you could even scan
for just the correct JAR file name(s).
Craig
Re: Problems while trying to share myfaces jars among various web applications
Posted by Heath Borders <he...@gmail.com>.
Well, the problem is that the FacesConfigurator only searches
WEB-INF/lib and META-INF/services for jars with the faces-config.xml
file.
Does this mean that during startup, we should try to check every jar
in the current thread's classloader hierarchy for jars with
faces-config.xml? That seems like it would take a lot of time.
On Thu, 30 Dec 2004 10:27:58 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Thu, 30 Dec 2004 18:54:41 +0100, Alessandro Polverini
> <al...@nibbles.it> wrote:
>
> > I've read and understood the documents Martin Cooper in another mail
> > pointed me at (thanks), anyway, this is what I read on the JSF specs,
> > paragraph 10.2.5 and 10.2.6:
> >
> > "These classes and resources comprise the implementation of the JSF APIs
> > that is provided by a JSF implementor. Typically, such classes will be
> > provided in the form of one or more JAR files, which can be either
> > installed with the container s shared class facility, or included in
> > the /WEB-INF/lib directory of a web application archive."
> >
> > So, if I'm not mistaken, the specs explicitly says that those jar can be
> > shared among all applications.
> >
>
> The spec does indeed *allow* for a JSF implementation to be shared in
> such a manner, placing it in a shared parent class loader. This will
> be important, for example, in the J2EE 5.0 platform, of which JSF 1.1
> will be a required part (so applications will be able to assume that
> it's built in, just like the servlet and JSP APIs are).
>
> What the spec does not cover (because it's an implementation issue) is
> that the *implementation* is responsible for making itself actually
> work when it is deployed in such a way. The most common issue is
> where the framework needs to instantiate an object of some class (such
> as a UIComponent) that is provided by the application. You need to
> load the class from the *application* class loader, rather than the
> class loader that loaded your framework, in order for these classes to
> be accessible.
>
> Fortunately, the server provides you convenient access to the webapp's
> class loader, so you can do things like this:
>
> String className = ...; // Name of some application provided class
> ClassLoader cl = Thread.currentThread().getContextClassLoader();
> Class clazz = cl.loadClass(className);
> UIComponent component = (UIComponent) clazz.newInstance();
>
> But the framework (in this cases, the MyFaces implementation of JSF)
> must be specifically programmed to do this kind of thing.
>
> Craig
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Problems while trying to share myfaces jars among various web applications
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 30 Dec 2004 18:54:41 +0100, Alessandro Polverini
<al...@nibbles.it> wrote:
> I've read and understood the documents Martin Cooper in another mail
> pointed me at (thanks), anyway, this is what I read on the JSF specs,
> paragraph 10.2.5 and 10.2.6:
>
> "These classes and resources comprise the implementation of the JSF APIs
> that is provided by a JSF implementor. Typically, such classes will be
> provided in the form of one or more JAR files, which can be either
> installed with the container s shared class facility, or included in
> the /WEB-INF/lib directory of a web application archive."
>
> So, if I'm not mistaken, the specs explicitly says that those jar can be
> shared among all applications.
>
The spec does indeed *allow* for a JSF implementation to be shared in
such a manner, placing it in a shared parent class loader. This will
be important, for example, in the J2EE 5.0 platform, of which JSF 1.1
will be a required part (so applications will be able to assume that
it's built in, just like the servlet and JSP APIs are).
What the spec does not cover (because it's an implementation issue) is
that the *implementation* is responsible for making itself actually
work when it is deployed in such a way. The most common issue is
where the framework needs to instantiate an object of some class (such
as a UIComponent) that is provided by the application. You need to
load the class from the *application* class loader, rather than the
class loader that loaded your framework, in order for these classes to
be accessible.
Fortunately, the server provides you convenient access to the webapp's
class loader, so you can do things like this:
String className = ...; // Name of some application provided class
ClassLoader cl = Thread.currentThread().getContextClassLoader();
Class clazz = cl.loadClass(className);
UIComponent component = (UIComponent) clazz.newInstance();
But the framework (in this cases, the MyFaces implementation of JSF)
must be specifically programmed to do this kind of thing.
Craig
Re: Problems while trying to share myfaces jars among various web
applications
Posted by Alessandro Polverini <al...@nibbles.it>.
On Thu, 2004-12-30 at 08:27 -0600, Heath Borders wrote:
> The problem is that JSF needs access to the jars in a uniform spot to
> configure the runtime. The spec says that it should act this way.
I've read and understood the documents Martin Cooper in another mail
pointed me at (thanks), anyway, this is what I read on the JSF specs,
paragraph 10.2.5 and 10.2.6:
"These classes and resources comprise the implementation of the JSF APIs
that is provided by a JSF implementor. Typically, such classes will be
provided in the form of one or more JAR files, which can be either
installed with the container s shared class facility, or included in
the /WEB-INF/lib directory of a web application archive."
So, if I'm not mistaken, the specs explicitly says that those jar can be
shared among all applications.
That is of course also a golden rule of software distribution: imagine
if I have N web applications using JSF and a security issue comes out:
in a shared context I just replace the updated jars while in the other
case I must manually check all the webapps using them and substitute
them one by one. Slow and error prone.
> Probably the best way around this is to see if your servlet container
> supports aliasing the jars. I'm running websphere, and i think
> there's a way that I could keep my jars in a common directory, but
> have my apps all reference them as though they were in their
> WEB-INF/lilb directories.
That's a nice feature from websphere but I'm stuck with tomcat 5.0.28
right now: maybe it has something equivalent? I did a quick search but
without any success.
Best regards,
Alex
Re: Problems while trying to share myfaces jars among various web applications
Posted by Heath Borders <he...@gmail.com>.
The problem is that JSF needs access to the jars in a uniform spot to
configure the runtime. The spec says that it should act this way.
Probably the best way around this is to see if your servlet container
supports aliasing the jars. I'm running websphere, and i think
there's a way that I could keep my jars in a common directory, but
have my apps all reference them as though they were in their
WEB-INF/lilb directories.
On Thu, 30 Dec 2004 15:21:53 +0100, Alessandro Polverini
<al...@nibbles.it> wrote:
> On Thu, 2004-12-30 at 08:04 -0600, Heath Borders wrote:
> > I think the FacesConfigurator requires that they be in the WEB-INF/lib
> > directory, I think putting them anywhere else starts making
> > assumptions about your web container.
>
> So if I have 10 (or 100) web applications I need to have 10 (or 100)
> copies of the *same* jars over and over?
>
> That seems a waste of space and resources to me. For example, when a new
> release is out, it's better to upgrade just one set of jars (like I do,
> for example with JSTL), instead of redeploy all the web applications,
> and look for the ones using myfaces.
>
> Is there any way to overcome the problem?
>
> Thanks for the reply,
> Alex
>
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Problems while trying to share myfaces jars among various web
applications
Posted by Alessandro Polverini <al...@nibbles.it>.
On Thu, 2004-12-30 at 08:04 -0600, Heath Borders wrote:
> I think the FacesConfigurator requires that they be in the WEB-INF/lib
> directory, I think putting them anywhere else starts making
> assumptions about your web container.
So if I have 10 (or 100) web applications I need to have 10 (or 100)
copies of the *same* jars over and over?
That seems a waste of space and resources to me. For example, when a new
release is out, it's better to upgrade just one set of jars (like I do,
for example with JSTL), instead of redeploy all the web applications,
and look for the ones using myfaces.
Is there any way to overcome the problem?
Thanks for the reply,
Alex