I got an NPE when I tried using the 1.1 impl in an webapp with the
1.2 api classes inherited from jee-specs. But I suspect that was due
to the classloader configuration rather than a backwards
compatibility problem. Certain JSF factory methods can return null
when the api and impl are in separate classloaders. That is one
reason why the spec is explicit about not including the JSF classes
in the web app due to JSF's the dependence on the "shared class
facilities of the servlet container" (see sections 10.2.5 and
10.2.6). Now I'm not altogether sure why overwriting the 1.2 api
jar with the 1.1 api jar in the repo worked. If it's important to
know then I can help investigate further.
Like David Jencks said, users that need JSF 1.1 in Geronimo's JEE5
web container could probably be supported by moving the myfaces api
jar from jee-specs to the myfaces config. But a user might wonder
then why Geronimo does not also support that approach for JSTL,
JAXWS, and other APIs that are part of the various JEE containers.
Maybe it should.
In the future JSRs 277, 291, and 294 will help JEE containers provide
this type of modularity. In the meantime maybe we can look into
David Carew's suggestion for configuring the application's
classloader based on its declared specification levels. That seems
like it could work for his specific case because the previous version
of JSF was not part of Java EE. But I am doubtful that its a good
approach for application deployment in general because I think users
would expect their legacy apps to benefit from the latest features
and bug fixes in the container in spite of being originally developed
against a previous version of the spec.
Best wishes,
Paul
On Nov 3, 2007, at 1:38 PM, David Jencks wrote:
I think we could move the myfaces non-overrideable classes into the
myfaces-builder default environment attribute. This would mean
that if you turn off the myfaces-deployer we wouldn't try to deploy
your jsf stuff as per javaee 5, and you shouldn't need to use
hidden-classes to avoid the myfaces 1.2 implementation. You'd
still be left with the jsf 1.2 api classes. What happens if you
try to run the myfaces < 1.2 implementation against the jsf 1.2
spec api classes?
Pretty much all the other spec jars seem to be backwards compatible
so we just use the latest versions. There may be some problem with
a SOAP related jar. We could consider attaching the jsf spec jar
to the myfaces module but this would probably have ripple effects
maybe through the tck tests.
thanks
david jencks
On Nov 3, 2007, at 6:33 AM, David Carew wrote:
I'm running into this issue too and it doesn't seem to care about the
J2EE version of the app being deployed. Shouldn't the behavior be
that
this only happens if the app in question is a JEE5 app ? Is there a
check in the code to branch around the additions to the plan for JSF
related stuff ? Unless the spec says that JSF support must be
implemented in a way to break J2EE 1.4 compatability. I think it
should allow J2EE 1.4 apps to use <hidden-classes> and include their
own JSF impl.
On Nov 2, 2007 11:34 AM, Paul McMahan <[EMAIL PROTECTED]> wrote:
Starting with Java EE 5 the JSF classes are provided by the web
container. The spec says that the JSF classes should not be
included
in the web application archive. When Geronmio deploys a webapp it
automatically merges this setting into webapp's deployment plan:
<non-overridable-classes>
<filter>java.</filter>
<filter>javax.</filter>
<filter>org.apache.geronimo.</filter>
<filter>org.apache.jasper.</filter>
<filter>org.apache.naming.</filter>
<filter>org.apache.catalina.</filter>
<filter>org.apache.tomcat.</filter>
<filter>org.apache.myfaces.</filter>
<filter>org.apache.taglibs.</filter>
<filter>org.xml.</filter>
<filter>org.w3c.</filter>
</non-overridable-classes>
The effect of this non-overridable-classes element as defined by the
Geronimo deployment schema is:
A list of classes which will only be loaded from parent
ClassLoaders of this module (never from the module's own
ClassLoader). For example, this is used to prevent a web
application from redefining "javax.servlet", so those
classes will *always* be loaded from the server instead
of from the web web application's own ClassPath.
This is why you saw the unexpected behavior when you tried to use
the
<hidden-classes> filter to load the JSF classes from your webapp.
In order to use the MyFaces 1.1.x in Geronimo 2.0 you would need to
stop or undeploy the myfaces and myfaces-deployer components before
deploying your webapp like David suggested. You would also need to
overwrite the MyFaces core api jar at:
geronimo/repository/org/apache/myfaces/core/myfaces-api/1.2.0/
myfaces-api-1.2.0.jar
with your desired version of MyFaces - using the same filename.
That jar (like all the other JavaEE API jars) is automatically
inherited by webapps deployed into Geronimo as a descendent of the
jee-specs component. I have verified that this works using the
MyFaces 1.1.5 sample app. Obviously after taking these steps you
would no longer have a JavaEE 5 compliant container since every JSF
enabled webapp in the container would be using the JSF 1.1 API.
Best wishes,
Paul
On Nov 1, 2007, at 1:30 PM, David Jencks wrote:
Paul may have more info, but my understanding is that for javaee
compliance we need to, by default, support myfaces 1.2 and ignore
any attempt to use earlier/other jsf implementations.
You might be able to disable this support by turning off the
myfaces and myfaces-deployer modules in config.xml by adding a
load="false" attribute. I can't promise this will work but it
might be worth a try.
thanks
david jencks
On Nov 1, 2007, at 8:57 AM, Jochen Zink wrote:
Hello all,
I try to deploy a JSF-Webapplication which depends on myfaces
1.1.5. This Application runs successfully under Tomcat 6.
Know, I want deploy this application under Geronimo 2.0.2. With
exactly the same WAR file, nothing is happen. No Error Messages
and no HTML Page is shown in the browser, if I call the URL from
the Webapplication. Just a empty page, containing no HTML appears.
I expect, that this could be, that Geronimo has myfaces1.2 Libs
loaded.
After this, I added
<dep:hidden-classes>
<dep:filter>org.apache.myfaces</dep:filter>
</dep:hidden-classes>
to the deploymentdescriptor of the Webapp.
And know I get the following Error Message, after calling the
WebApplication URL:
Some Messages looks like this:
An error occurred at line: 114 in the jsp file: /template.jsp
The method setHeight(String) in the type HtmlGraphicImageTagBase
is not applicable for the arguments (JspValueExpression)
111:
<h:graphicImage value="pics/spacer.gif" width="0"
height="20" />
112:
<h:outputText />
113:
<h:graphicImage value="pics/spacer.gif" width="0"
height="20" />
114:
<h:graphicImage value="pics/spacer.gif" width="0"
height="20" />
115:
116:
<h:outputText />
117:
<h:outputText />
And an Exception which looks like:
javax.servlet.ServletException: java.lang.InstantiationException:
Can't load class org.apache.jsp.template_jsp in classloader:
[EMAIL PROTECTED]
javax.faces.webapp.FacesServlet.service(FacesServlet.java:
152)
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter
(ExtensionsFilter.java:147)
root cause
javax.faces.FacesException: java.lang.InstantiationException:
Can't load class org.apache.jsp.template_jsp in classloader:
[EMAIL PROTECTED]
org.apache.myfaces.context.servlet.ServletExternalContextImpl.disp
atc
h(ServletExternalContextImpl.java:425)
org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImp
l.d
ispatch(JspTilesViewHandlerImpl.java:236)
org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImp
l.r
enderView(JspTilesViewHandlerImpl.java:222)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute
(RenderResponseExecutor.java:41)
org.apache.myfaces.lifecycle.LifecycleImpl.render
(LifecycleImpl.java:132)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:
138)
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter
(ExtensionsFilter.java:147)
Has anyone an idea, what I must do, to use myfaces 1.1.5 with
geronimo 2.0.2?
We're not able to switch to myfaces 1.2!
Thanks!
Regards
Jochen
__________________________________________________________________
___
__
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?
mc=022220
