Sorry, I misread the initial post. I thought Eric suggested setting the 
classloader for the web module to parent_last (yes, there are two places to set 
this).  That's the first one I usually set. Hence my suggestion you might also 
need to set the classloader for the EAR.
 
To solve all classloader issues like this, google for "mustgather classloader 
issues site:ibm.com", and you are shown all IBM mustgather pages for the 
various incarnations of WAS. They show you how to enable tracing and using 
trace.log you can find the jar used to load your classes. 
 
BTW: typical you need google to find anything on the IBM site ;-)
 
Regards, 
Erik-Berndt Scheper

________________________________

Van: Scheper, Erik-Berndt [mailto:[EMAIL PROTECTED]
Verzonden: wo 26-4-2006 21:43
Aan: MyFaces Development
Onderwerp: RE: Myfaces running on WebSphere Application Server v6.1


Yes, this should work. Sometimes you have to set the classloader for the EAR to 
parent_last as well (especially if you include jar's in the EAR and add them to 
the manifest in the war file.
The cause of this issue is that IBM has packaged its own (and very buggy I 
might add) version of the JSF reference implementation with WAS 6.0.
The same is required if you want to use commons logging within your web 
application as IBM has wisely included its own version of this as well (without 
updating the package structure).
 
Regards,
Erik-Berndt Scheper
Sogeti Nederland BV

________________________________

Van: [EMAIL PROTECTED] namens Eric Hedström
Verzonden: wo 26-4-2006 21:36
Aan: MyFaces Development
Onderwerp: Re: Myfaces running on WebSphere Application Server v6.1


The better approach is to set the classloader policy for your web module in the 
"Enterprise Application" to "Parent last". This tells WebSphere that for your 
application, you want it to favor the libraries in the WAR over those bundled 
with WebSphere. 

We've run into this problem with several JARs (JDOM, Mozilla Rhino js.jar, 
etc.) for which Websphere includes an older version or its own custom version. 
Customers definitely prefer this approach to hacking on the app server itself. 

The app I'm working on now is using the Sun RI impl with Tomahawk 1.1. Without 
the classloader setting it chokes even on the Sun RI.

Eric


On 4/20/06, Thomas Spiegl <[EMAIL PROTECTED]> wrote: 

        You may find this helpful
        http://wiki.apache.org/myfaces/Websphere_Installation
        
        On 4/20/06, Graham Crooks < [EMAIL PROTECTED] <mailto:[EMAIL 
PROTECTED]> > wrote:
        >
        > I am porting on behalf of a software house, an application  that is 
currenly
        > running on Tomcat Server under Redhat Linux.
        > The developer has made extensive use of the MyfacesTomahawk 
extensions and 
        > these seem to work fine in Tomcat but within WebSphere Appication 
Server
        > anything that is declared between the tomahawk specific tags is not
        > displayed.
        >
        > The message I am seeing is: ERROR 
        > [org.apache.myfaces.lifecycle.LifecycleImpl] - <Assumed extension 
mapping,
        > but there is no extension in /software/>
        > 
[org.apache.myfaces.lifecycle.LifecycleImpl.deriveViewId(LifecycleImpl.java 
:422)]
        >
        > After lots of log setting I know that this error is NOT being 
produced by
        > Websphere
        > in fact it appears in the /home/user1/logs/error.log, and I believe 
this is
        > being written to by: 
        > org/apache/myfaces/lifecycle/LifecycleImpl.java
        >
        > This is the MyFaces extension declarations within the web.xml
        > <filter>
        >         <filter-name>MyFacesExtensionsFilter</filter-name> 
        >
        > 
<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
        >     <init-param>
        >         <param-name>maxFileSize</param-name>
        >         <param-value>20m</param-value> 
        >     </init-param>
        >         </filter>
        >
        >     <filter-mapping>
        >         <filter-name>MyFacesExtensionsFilter</filter-name>
        >                 <url-pattern>/software</url-pattern> 
        >         </filter-mapping>
        >
        > /software resolves to the JSF servlet.
        >
        > I have tried changing around the /software to /*.jsf etc but this 
doesn't
        > make any difference.
        > Can anyone tell me where I might start trying to look to figure this 
        > through.Tks
        > --
        > View this message in context: 
http://www.nabble.com/Myfaces-running-on-WebSphere-Application-Server-v6.1-t1480412.html#a4006869
 
        > Sent from the My Faces - Dev forum at Nabble.com.
        >
        >
        
        
        --
        http://www.irian.at
        
        Your JSF powerhouse -
        JSF Consulting, Development and 
        Courses in English and German
        
        Professional Support for Apache MyFaces
        




Disclaimer:
This message contains information that may be privileged or confidential and is 
the property of Sogeti Nederland B.V. or its Group members. It is intended only 
for the person to whom it is addressed. If you are not the intended recipient, 
you are not authorized to read, print, retain, copy, disseminate, distribute, 
or use this message or any part thereof. If you receive this message in error, 
please notify the sender immediately and delete all copies of this message.

<<winmail.dat>>

Reply via email to