geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <paulmcma...@gmail.com>
Subject Re: MyFaces 1.1.5 and Geronimo 2.0.2
Date Mon, 05 Nov 2007 22:58:03 GMT
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 <paulmcmahan@gmail.com> 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:
>>>>> org.apache.jasper.servlet.JasperLoader@106fbae
>>>>>      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:
>>>>> org.apache.jasper.servlet.JasperLoader@106fbae
>>>>>
>>>>> 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
>>>>>
>>>>
>>>
>>>
>


Mime
View raw message