Skip to main content

JSF 2.0: Mojarra on JBoss and WebSphere?

24 replies [Last post]
martyhall
Offline
Joined: 2009-08-19

I have a client that is starting a new project. I recommended JSF 2.0, but the client is worried that JSF 2.0 won't run on their deployment servers, which are JBoss and WebSphere. I have had no problem running Mojarra on Tomcat, so I think JBoss is safe. But what about WebSphere?

Does anyone know the exact JBoss and WebSphere versions needed for the Mojarra JSF 2.0 implementation?

Cheers-

- Marty
-----
JSF 2.0 Tutorial: http://www.coreservlets.com/JSF-Tutorial/jsf2/

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
fmt
Offline
Joined: 2010-05-21

Hi,

We are currently trying to use our specific JSF 1.2 implementation on WebSphere 7 because the one bundled inside WAS by IBM is causing problems...

But when we specify our own implementation, it breaks the EJB3 dependency injection.

I'd be very glad if you could provide me an example of InjectionProvider and how to configure it in WebSphere !

Thanks in advance,
Fmt

fmt
Offline
Joined: 2010-05-21

Hi again,

An IBM Injection Provider exists already in com.ibm.ws.webcontainer.jar (WebSphere 7.0.0.9): com.sun.faces.vendor.WebSphereInjectionProvider.
In order to use it as injection provider with a custom implementation, you must declare it like this in your web.xml:

In order to make the JSF dependency injection work in WebSphere

com.sun.faces.injectionProvider com.sun.faces.vendor.WebSphereInjectionProvider

For my needs, I made a class based on the IBM one with reflexion to avoid the need to provide all the IBM WAS 7 runtime to compile the class (we are using maven in our projects). I used slf4j as log facade but this can easily be changed.

It works well with the last JSF 1.2 version. I didn't tried it with JSF 2.0 but it should be similar.

Hope it's useful for somebody.

Regards,
Florian Minjat

Here is the class (sorry for the formatting, I didn't know where to put it):

package com.sun.faces.vendor;

import java.lang.reflect.Method;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.servlet.ServletContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.sun.faces.spi.DiscoverableInjectionProvider;
import com.sun.faces.spi.InjectionProviderException;
import com.sun.faces.util.Util;

/**
* This class provides Dependency Injection and Pre/Post Construct on JSF ManagedBeans (tested with JSF 1.2_14)
* It's based on IBM com.sun.faces.vendor.WebSphereInjectionProvider class from com.ibm.ws.webcontainer.jar (WebSphere 7.0.0.9)
*
* @author fmt
*/
public class WebSphereInjectionProvider extends DiscoverableInjectionProvider {
private static final Logger LOG = LoggerFactory.getLogger(WebSphereInjectionProvider.class);

private static final String WEBSPHERE_ANNOTATION_HELPER_MANAGER_CLASS = "com.ibm.wsspi.webcontainer.annotation.AnnotationHelperManager";
private Object runtimeAnnotationHelper;

/**
* invoke com.ibm.wsspi.wetainer.annotation.AnnotationHelperManager.getInstance(ServletContext context);
* then com.ibm.wsspi.wetainer.annotation.AnnotationHelperManager.getAnnotationHelper()
*/
public WebSphereInjectionProvider() {
try {
ExternalContext externalContext = FacesContext.getCurrentInstance().getExternalContext();
Class clazz = Util.loadClass(WEBSPHERE_ANNOTATION_HELPER_MANAGER_CLASS, WebSphereInjectionProvider.class);
Method mGetInstance = clazz.getMethod("getInstance", new Class[] {ServletContext.class});
Method mGetAnnotationHelper = clazz.getMethod("getAnnotationHelper", new Class[] {});
Object annotationHelperManager = mGetInstance.invoke(null, (ServletContext) externalContext.getContext());
this.runtimeAnnotationHelper = mGetAnnotationHelper.invoke(annotationHelperManager, new Object[] {});
if (LOG.isInfoEnabled()) { LOG.info("WebSphere injection provider successfully loaded.");
} catch (Exception e) {
LOG.error("WebSphere injection provider initialisation failed: " + e, e);
}
}

/**
* invoke com.ibm.wsspi.wetainer.annotation.AnnotationHelper.inject(Object managedBean)
*/
public void inject(Object managedBean) throws InjectionProviderException {
try {
Method mInject = runtimeAnnotationHelper.getClass().getMethod("inject", new Class[] {Object.class});
mInject.invoke(runtimeAnnotationHelper, managedBean);
if (LOG.isDebugEnabled()) { LOG.debug("inject(managedBean='"+managedBean+"') OK !"); }
} catch (Exception e) {
LOG.error("inject(managedBean='"+managedBean+"') KO: " + e, e);
throw new InjectionProviderException(e);
}
}

/**
* invoke com.ibm.wsspi.wetainer.annotation.AnnotationHelper.doPreDestroy(Object managedBean)
*/
public void invokePreDestroy(Object managedBean) throws InjectionProviderException {
try {
Method mInject = runtimeAnnotationHelper.getClass().getMethod("doPreDestroy", new Class[] {Object.class});
mInject.invoke(runtimeAnnotationHelper, managedBean);
if (LOG.isDebugEnabled()) { LOG.debug("invokePreDestroy(managedBean='"+managedBean+"') OK !"); }
} catch (Exception e) {
LOG.error("invokePreDestroy(managedBean='"+managedBean+"') KO: " + e, e);
throw new InjectionProviderException(e);
}
}

/**
* invoke com.ibm.wsspi.wetainer.annotation.AnnotationHelper.doPostConstruct(Object managedBean)
*/
public void invokePostConstruct(Object managedBean) throws InjectionProviderException {
try {
Method mInject = runtimeAnnotationHelper.getClass().getMethod("doPostConstruct", new Class[] {Object.class});
mInject.invoke(runtimeAnnotationHelper, managedBean);
if (LOG.isDebugEnabled()) { LOG.debug("invokePostConstruct(managedBean='"+managedBean+"') OK !"); }
} catch (Exception e) {
LOG.error("invokePostConstruct(managedBean='"+managedBean+"') KO: " + e, e);
throw new InjectionProviderException(e);
}
}

public static boolean isInjectionFeatureAvailable(String delegateClass) {
try {
Util.loadClass(delegateClass, null);
return true;
} catch (Exception e) {
LOG.error("isInjectionFeatureAvailable(delegateClass='"+delegateClass+"') KO: "+e, e);
}
return false;
}
}

ragesteel
Offline
Joined: 2010-02-09

Thank to fmt for pointing to sample implementation of InjectionProvider. I'm not tested it for JSF 1.2, but it is not enought for JSF 2.0.
I've tried JSF RI 2.0.4 with WebSphere 7, jsf2 jars are deployed as isolated shared library -- the way that IBM told us to do http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/c...
After configuring custom jsf implementation we need to add listener to our web.xml:

 <listener>
  <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>

Injection of EJBs in JSF's Managed Beans are worked only if Managed Beans are specified in the faces-config.xml. For Managed Beans defined by @ManagedBean annotation EJB injection simple does not work.
I've made some research and found that WebSphere's AnnotationHelper have a method getClassesToScan() returning List<Class>. After i've manually added some classes to this list, EJB injection started to work for these added classes. So we need to add list of classes, annotated by @ManagedBean and recognized by JSF to this list.
But this only the half of the problem -- lifecycle methods (annotated with @PostConstruct and @PreDestroy) are not called, after I configured JSF to use my Was7InjectionProvider. And i took a simplest solution -- created a instance of base WebContainerInjectionProvider and delegated methods invokePostConstruct and invokePreDestory to it.
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import java.util.logging.Level;
import java.util.logging.Logger;

import javax.faces.bean.ManagedBean;
import javax.faces.context.FacesContext;
import javax.servlet.ServletContext;

import com.ibm.wsspi.webcontainer.annotation.AnnotationHelper;
import com.ibm.wsspi.webcontainer.annotation.AnnotationHelperManager;
import com.sun.faces.config.ConfigManager;
import com.sun.faces.spi.DiscoverableInjectionProvider;
import com.sun.faces.spi.InjectionProviderException;
import com.sun.faces.vendor.WebContainerInjectionProvider;

/**
* InjectionProvider for JSF2 RI for WebSphere Application Server v7
*/
public class Was7InjectionProvider extends DiscoverableInjectionProvider {

public static final String CLASS_NAME = Was7InjectionProvider.class.getName();
private static final Logger LOGGER = Logger.getLogger(Was7InjectionProvider.CLASS_NAME);

private AnnotationHelper annotationHelper;
private AnnotationHelperManager annotationHelperManager;
private WebContainerInjectionProvider lifecycleHelper;

public Was7InjectionProvider() {
FacesContext currentInstance = FacesContext.getCurrentInstance();
ServletContext servletContext = (ServletContext) currentInstance.getExternalContext().getContext();
annotationHelperManager = AnnotationHelperManager.getInstance(servletContext);
annotationHelper = annotationHelperManager.getAnnotationHelper();

lifecycleHelper = new WebContainerInjectionProvider();
addAnnotatedManagedBeans(currentInstance);
}

/**
* {@inheritDoc}
*/
@Override
public void inject(Object managedBean) throws InjectionProviderException {
try {
annotationHelper.inject(managedBean);
} catch (Exception ie) {
throw new InjectionProviderException(ie);
}
}

/**
* {@inheritDoc}
*/
@Override
public void invokePostConstruct(Object managedBean)
throws InjectionProviderException {
try {
lifecycleHelper.invokePostConstruct(managedBean);
} catch (Exception ie) {
throw new InjectionProviderException(ie);
}
}

/**
* {@inheritDoc}
*/
@Override
public void invokePreDestroy(Object managedBean)
throws InjectionProviderException {
try {
lifecycleHelper.invokePreDestroy(managedBean);
} catch (Exception ie) {
throw new InjectionProviderException(ie);
}
}

private void addAnnotatedManagedBeans(FacesContext currentInstance) {
// Target list of classes
List&lt;Class&lt;?&gt;&gt; classesToScan = annotationHelper.getClassesToScan();
// Getting list of classes annotaded with @ManagedBean
Set&lt;Class&lt;?&gt;&gt; managedBeanClasses = ConfigManager.getAnnotatedClasses(currentInstance).get(ManagedBean.class);
// Make a copy
Set&lt;Class&lt;?&gt;&gt; classesToAdd = new HashSet&lt;Class&lt;?&gt;&gt;(managedBeanClasses);
// Remove classes that already exist in list
classesToAdd.removeAll(classesToScan);
if (classesToAdd.isEmpty()) {
LOGGER.log(Level.INFO, &quot;No @ManagedBean classes to add&quot;);
} else {
LOGGER.log(Level.INFO, &quot;Adding the following @ManagedBean classes: {0}&quot;, classesToAdd);
// Addeding result to target list of classes
classesToScan.addAll(classesToAdd);
}
}

}

<br />

We also used maven for building artifacts, and I put com.ibm.ws.webcontainer.jar, that needed to build presented class to local maven repository managed running nexus.
So there is only one strange thing remainging, on the startup of application, WebSphere say that is initializing JSF 1.2:
[4/6/11 15:58:22:438 MSD] 00000049 config        I   Initializing Sun's JavaServer Faces implementation (1.2_07-b03-FCS) for context '/front.web'

But this is not true, for the specified context JSF2-only features are working in this context!

kennas
Offline
Joined: 2006-02-14

Agree with your setup to incorporate JSF 2 into WebSphere 7.

Have you tried to inject something into a managed bean?

rdean400
Offline
Joined: 2010-01-23

I tried it, but wasn't successful. I found a tech note somewhere that said that WebSphere's injection engine will only inject into Java EE 5 defined resources (servlets, listeners, etc), and managed beans don't qualify as such. I thought about looking into Weld, but I haven't done anything with that yet.

rseguy
Offline
Joined: 2009-02-16

I tried too but wasn't successful. I raised a PMR to IBM which went up to the dev team, who ended confirming that a specific Mojarra injection provider has to be developed. Some links to develop such an injection provider:
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and
https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_01/changelog.html...

I'll take a look soon to evaluate the workload.

mjdenham
Offline
Joined: 2006-01-19

It is a year or so since I played around with JSF 2 on websphere but I got the have a simple JSF 2 web app working under Websphere 6.1 and also created a simple Injection Provider for Websphere that at least injects a stateless session bean correctly.

But one interesting point is that JSF 2 works on Websphere 6.1 which implements Servlet 2.4 not 2.5. It may be that you only need Servlet 2.5 if using jsp and not Facelets xhtml.

Unfortunately I did this a long time ago and can't recall the details but if anybody is interested I can make it available somewhere and I can do some more tests on other samples.

We are are stuck on Websphere 6.1 for the next couple of years at least so it would be nice to get some authoritative feedback on whether JSF 2 is supposed to work on that platform.

Lincoln Baxter, III

JSF 2.0 requires servlet 2.5 (definitive answer)

On Wed, Apr 14, 2010 at 11:49 AM, wrote:

> It is a year or so since I played around with JSF 2 on websphere but I got
> the have a simple JSF 2 web app working under Websphere 6.1 and also created
> a simple Injection Provider for Websphere that at least injects a stateless
> session bean correctly.
>
> But one interesting point is that JSF 2 works on Websphere 6.1 which
> implements Servlet 2.4 not 2.5. It may be that you only need Servlet 2.5 if
> using jsp and not Facelets xhtml.
>
> Unfortunately I did this a long time ago and can't recall the details but
> if anybody is interested I can make it available somewhere and I can do some
> more tests on other samples.
>
> We are are stuck on Websphere 6.1 for the next couple of years at least so
> it would be nice to get some authoritative feedback on whether JSF 2 is
> supposed to work on that platform.
> [Message sent by forum member 'mjdenham']
>
> http://forums.java.net/jive/thread.jspa?messageID=396940
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>
>

--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
[att1.html]

magnn
Offline
Joined: 2010-04-21

I've successfuly deployed/run a [b]simple JSF 2.0 application (facelets, no jsp) on Tomcat 5.5[/b] (Servlet 2.4), so I wonder what JSF 2.0 features/functionality won't work on Servelt 2.4?

> JSF 2.0 requires servlet 2.5 (definitive answer)
>
> On Wed, Apr 14, 2010 at 11:49 AM,
> wrote:
>
> > It is a year or so since I played around with JSF 2
> on websphere but I got
> > the have a [b]simple JSF 2 web app working under Websphere 6.1[/b]

rsandhu
Offline
Joined: 2010-02-22

I got it to work and i'll describe the sequence of steps for it below:

1. my test war worked on tomcat out of the box and it didn't in WAS 7.0....just FYI for everyone.

2. my jsf files were .xhtml, so maybe they need to be jsp / jsf extension to work, but i don't really think so since all files were mapped to the faces servlet in the web.xml, just throwing it out there.

3. i added the jsf 2.0 libs from mojarra/lib directly to WAS lib directory and restarted server. that didn't work....did WAS even load the jars into memory ?

4. i found and tried the class loader settings tweak, mentioned in the post above, that doesn't work. the error is "Error 500: javax.servlet.ServletException: SRVE0207E: Uncaught initialization exception created by servlet "....i think it can't find the faces servlet or at least version 2.0.
i set class loader priority to child first at both server and application level, it makes no difference.

5. i also messed around with the jsf settings, but neither work either.

AND NOW FOR THE SOLUTION:

i added the lib directory containing the jsf 2.0 jars under web-inf...just copy and paste, restart app. and viola, it works. note, i had child class loader set first.

why java doesn't have better class loader/conflict diagnostics programs is a mystery to me. NoClassDef for Life :)

mpscholz
Offline
Joined: 2003-06-12

Depends on your needs, I'd think: Servlet 2.5 and a JEE 5 complaint container should suffice for now, but note that you will need even a servlet 3.0 compliant container in case you want to make use of JSF tag libraries that rely on servlet 3.0 specific features (like PrimeFaces which comes along with [i]web-fragment[/i] entries).

And some JSF 2.0 features (like the passing of method parameters in the Unified Expression Language) will require a JEE 6 compliant container (JBoss 6 or Glassfish 3 at this point of time).

kennas
Offline
Joined: 2006-02-14

I do not believe that resource injection will work in your managed beans in WAS v7 unless you write your own InjectionProvider for Mojarra's JSF 2.

rdean400
Offline
Joined: 2010-01-23

I'm just getting back to this thread after burning through some vacation time. :-)

There are two ways to get WebSphere 7 to use JSF 2:

Good:
- Put jsf-api.jar and jsf-impl.jar in WEB-INF/lib and set module classloader to PARENT_LAST

Better:
- Put jsf-api.jar and jsf-impl.jar in the server filesystem, create a shared library (isolated classloader checked), and assign the shared library to the web module.

rdean400
Offline
Joined: 2010-01-23

Sorry, hooked the response to the wrong place. :-(

martyhall
Offline
Joined: 2009-08-19

BTW, just wanted to say thanks to folks on this thread (and the spinoff thread on using JSF 2.0 on WebSphere). My clients officially agreed to my recommendation and are using JSF 2.0 on their project.

Cheers-

- Marty
-----------
JSF 2.0 Training Course: http://courses.coreservlets.com/public-courses/jsf2/

Ed Burns

>>>>> On Thu, 11 Mar 2010 05:55:32 -0800 (PST), webtier@javadesktop.org said:

M> BTW, just wanted to say thanks to folks on this thread (and the
M> spinoff thread on using JSF 2.0 on WebSphere). My clients officially
M> agreed to my recommendation and are using JSF 2.0 on their project.

As the kids say, "that's full of win". (yuck, can't stand that usage).

Anyhow, Marty, please consider adding a reference to the
RealWorldJsfLinks wiki page .

That goes for everyone here as well.

Ed

--
| edward.burns... | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

rsandhu
Offline
Joined: 2010-02-22

Hi,

i just installed Websphere 7 (trial version) from their website. Then i downloaded mojarra-2.0.2-FCS and using maven built the war for the helloworld app. in the samples dir. Then I downloaded apache-tomcat-6.0.24 and using it's web based admin deployed the war. tested the app. in the browser and it works fine.

then i deployed the same war in Websphere and when i go to the app. root i get the raw .xhtml rendered as xml, it is not processed to html !!! (there are no .jsf or .jsp in this app.)......i added mojarra libs to WAS libs and restarted -- no help....fiddled with jsf settings on admin page for the webapp....it gives 2 options sun 1.1 or apache 1.2 myfaces and makes no difference.

anybody have any suggestions or ideas, please !!!!

ranjit sandhu

coupelon
Offline
Joined: 2007-11-26

Hi,

You don't have to mess with the jsf settings on WAS 7, when you deploy manually you need to set the PARENT_LAST setting in the deployed module.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzatz/51/pro...

Jsf settings on the WAS configuration are only there for embedded versions of JSF, not for JSF 2.0.
Just take a look at the source code I provided earlier in that thread for more information.

rdean400
Offline
Joined: 2010-01-23

I can confirm that Mojarra 2.0 works on WebSphere 7+. I recently installed a production application with it.

There is one issue we encountered with jsf.js (Mojarra throws an error saying that jsf.js couldn't be found), but I haven't spent time on it yet. I worked around it by extracting the file and including it in the master template, for now.

Jason Lee

That's great to hear that you got it working on WS. When you get some
time, if you could do some digging into the jsf.js problem and file
issue, we'd really appreciate it. It looks like there's a free demo for
WS 7, so a small test case would be helpful.

Thanks. :)

On 2/21/10 7:17 PM, webtier@javadesktop.org wrote:
> I can confirm that Mojarra 2.0 works on WebSphere 7+. I recently installed a production application with it.
>
> There is one issue we encountered with jsf.js (Mojarra throws an error saying that jsf.js couldn't be found), but I haven't spent time on it yet. I worked around it by extracting the file and including it in the master template, for now.
> [Message sent by forum member 'rdean400' (rdean400@yahoo.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=387905
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>
>

--
Jason Lee
Senior Java Developer
GlassFish Administration Console

Sun Microsystems, Inc.
Phone x31197/+1 405-343-1964
Email jasondlee@sun.com
Blog http://blogs.sun.com/jasondlee
Blog http://blogs.steeplesoft.com

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

coupelon
Offline
Joined: 2007-11-26

Hello,

Just like rdean400, we are also running JSF 2.0 on WAS 7, and I can confirm that it *mostly* work.
The problem with jsf.js is more like a global problem of resource access, as I'll depict in the following.

My company is currently looking forward to use JSF 2.0 in production, while keeping their currently running servers, i.e. using Websphere Application Server 7.

Here is a simple test program that illustrates the problem more deeply, but doesn't gives us any hints on how to solve it.

Were are using the following tools :

- Maven 2.2.1
- WAS 7.0.0.7 and WAS 7.0.0.5
- JSF 2.0.2 RI (Mojarra 2.0.2 (FCS b10))
- The EL version shipped with WAS 7 is sufficient for that test, but we are using version 2.2 for development.
- using WAS PARENT_LAST configuration for WAR and EAR deployment classloader. The module loader is also set to PARENT_LAST.

In the given test case, the following piece of log indicates that Mojarra is indeed loaded with the application startup :
[24/02/10 17:02:49:258 CET] 0000001b config I Initialisation de Mojarra 2.0.2 (FCS b10) pour le contexte '/Prototype-test'

The test project is architectured as follow, using three subprojects :

- A project (components-projectTest folder) for the components (only one in that case) with the following files :
* META-INF\resources\projectTest\composantTest.xhtml which is the component's code
* A class com\project\portailvalorisation\components\ComposantTestBean.java used by the component
* META-INF\faces-config.xml
* META-INF\projecttest.taglib.xml

- A project for generating the web application, using the component defined below.
* The component is thus packaged as a JAR in the WEB-INF\lib folder.
* The index.xhtml page is using the component.

- An EAR project for deploying the application directly to WAS, preconfigured. That project takes care of setting the PARENT_LAST properties.

This is a standard configuration AFAIK, and we tested that project successfully on JBoss 6.0.0.M2 and Glassfish v3 without problems.
The problem we encounter with WAS 7 is the same that the one encountered with jsf.js, the components resources cannot be accessed, i.e. the namespace resolves correctly regarding to the component, but the xhtml page cannot be found.
If we explode the component's JAR content from WEB-INF/lib into our WAR, the resources can then be found (but then the java classes are misplaced), and we can use the application as expected. It is important to understand that within the JAR file, the other files can still be found, for instance xml configuration files, java classes. The problem only occurs with resources (XHTML, CSS...).
What happens here is that when the content of the JAR is exploded into the WAR, the ressources are relocated in the META-INF\resources folder of the root webapp project, and thus made accessible.

Here is a complete execution log of the project startup from WAS 7 (in french, sorry, i can translate if needed) :

[24/02/10 17:02:48:430 CET] 0000001b AdminHelper A ADMN1009I: Tentative de démarrage de l'application Prototype_1.0.0.
[24/02/10 17:02:48:462 CET] 0000001b CompositionUn A WSVR0190I: Démarrage de l'unité de composition WebSphere:cuname=Prototype_1.0.0 dans l'application BLA WebSphere:blaname=Prototype_1.0.0.
[24/02/10 17:02:49:087 CET] 0000001b ApplicationMg A WSVR0200I: Lancement de l'application Prototype_1.0.0
[24/02/10 17:02:49:087 CET] 0000001b ApplicationMg A WSVR0204I: Application : Prototype_1.0.0 Niveau de compilation d'application : Inconnu
[24/02/10 17:02:49:118 CET] 0000001b ResourceMgrIm I WSVR0049I: Liaison de DefaultEJBTimerDataSource en tant que jdbc/DefaultEJBTimerDataSource
[24/02/10 17:02:49:149 CET] 0000001b webapp I com.ibm.ws.webcontainer.webapp.WebGroupImpl WebGroup SRVE0169I: Chargement du module Web : Prototype-test-1.0.0.war.
[24/02/10 17:02:49:165 CET] 0000001b WASSessionCor I SessionContextRegistry getSessionContext SESN0176I: Un nouveau contexte de session va être créé pour la clé d'application default_host/Prototype-test
[24/02/10 17:02:49:258 CET] 0000001b config I Initialisation de Mojarra 2.0.2 (FCS b10) pour le contexte '/Prototype-test'
[24/02/10 17:02:49:790 CET] 0000001b application I JSF1048 : Présence d''annotations PostConstruct/PreDestroy Les méthodes de beans gérés marquées avec ces annotations auront des annotations dites traitées.
[24/02/10 17:02:50:133 CET] 0000001b config I Monitoring file:/C:/Program Files/IBM/SDP/runtimes/base_v7/profiles/was70profile1/installedApps/CL-CL06Node02Cell/Prototype_1.0.0.ear/Prototype-test-1.0.0.war/WEB-INF/faces-config.xml for modifications
[24/02/10 17:02:50:149 CET] 0000001b servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [Prototype_1.0.0] [/Prototype-test] [Faces Servlet] : L'initialisation a abouti.
[24/02/10 17:02:50:149 CET] 0000001b webcontainer I com.ibm.ws.wswebcontainer.VirtualHost addWebApplication SRVE0250I: Module Web null lié à default_host[*:9081,*:80,*:9444,*:5063,*:5062,*:443].
[24/02/10 17:02:50:149 CET] 0000001b ApplicationMg A WSVR0221I: L'application est lancée : Prototype_1.0.0
[24/02/10 17:02:50:149 CET] 0000001b CompositionUn A WSVR0191I: L'unité de composition WebSphere:cuname=Prototype_1.0.0 dans l'application BLA WebSphere:blaname=Prototype_1.0.0 a démarré.
[24/02/10 17:02:58:540 CET] 00000021 lifecycle I JSF1027 : [/Prototype-test] Les objets ELResolvers de JSF n'ont pas été enregistrés avec le conteneur JSP.
[24/02/10 17:02:58:587 CET] 00000021 context W JSF1091 : Aucun type mime détecté pour le fichier composantTest.xhtml. Pour résoudre ce problème, ajoutez un mappage mime-type au fichier web.xml de l'application.
[24/02/10 17:02:58:587 CET] 00000021 application W JSF1064 : Impossible de localiser ou de servir une ressource, composantTest.xhtml, depuis la bibliothèque projectTest.

Please note the last error JSF1064 indicating that the xhtml resource can't be found. This error is generated when we try to access the index.xhtml page.
The JSF page produced displays the following error :
/index.xhtml @15,32
Tag Library supports namespace: http://www.project.com/projectTest, but no tag was defined for name: composantTest

To compile the project, please use the
mvn -P WAS7 clean install
command for replicating the described error, and
mvn -P WAS7Bypass clean install
to make it work by exploding the JAR content.

The example normal behavior is to display the string "If you see this message, the Test component is working". To compile a war for Glassfish v3, just use the JBoss6 maven profile, and deploy the WAR (the EAR is still specific to WAS7).

Activating the JSF log from WAS 7 doesn't indicate any other error (finest on javax.enterprise.resource.webcontainer.jsf.*), while displaying many more information.

This is really a critical problem for us, determining the possible adoption of the technology, since it prevents us from testing and deploying easily our code (we have to explode our components manually into our WAR (using the maven-dependency-plugin) which is incompatible with the debugging process of RAD7.5, our IDE).

Please tell me if you need any more information.

The source code is available at http://dl.free.fr/pFNMYGoBT (If its written in french please click on 'Télécharger ce fichier' which translates to 'Download that file').

Olivier COUPELON

coupelon
Offline
Joined: 2007-11-26

Does someone have an idea on how to correct such problem ? For your interest, there is a version of the websphere application server 7 available at IBM at no charge : http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/learn.html

Should I create a new thread ? This one has been marked as answered...

Thanks in avance,

Olivier COUPELON

Lincoln Baxter, III

You need a Servlet container that supports Servlet 2.5 (JBoss 5+, WAS 7+)

On Fri, Feb 19, 2010 at 3:27 PM, wrote:

> I have a client that is starting a new project. I recommended JSF 2.0, but
> the client is worried that JSF 2.0 won't run on their deployment servers,
> which are JBoss and WebSphere. I have had no problem running Mojarra on
> Tomcat, so I think JBoss is safe. But what about WebSphere?
>
> Does anyone know the [u]exact [/u]JBoss and WebSphere versions needed for
> the Mojarra JSF 2.0 implementation?
>
> Cheers-
>
> - Marty
> -----
> JSF 2.0 Tutorial: http://www.coreservlets.com/JSF-Tutorial/jsf2/
> [Message sent by forum member 'martyhall' (hall@coreservlets.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=387669
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>
>

--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
[att1.html]

martyhall
Offline
Joined: 2009-08-19

> You need a Servlet container that supports Servlet 2.5 (JBoss 5+, WAS 7+)

Thanks, Lincoln. I passed on your info to them; much appreciated. I'd really like to see these clients go with JSF 2.0, so I hope this jibes with the versions they now have installed.

Cheers-

- Marty