I have problems running JSF in an OSGi environment. I am using jetty web container and equinox to provide the OSGi functionality. The structure of my application is as follows:
The first bundle has all the JSF libs, web.xml and a config.xml. It looks as the following:
bundle1
----src/main/java
-------de/package
----------Activator.java
----------JSFResolver.java
----src/main/resource
------ WebContent
----------META-INF
-------------face-config.xml
-------------web.xhtml
----------start.xhtml
-----------include.xhtml
----libs (containing all JSF required Jars)
The structure of the second bundle is as follows:
bundle2
---src/main/java
------de/package
----------Bean.java
---src/main/resource
------META-INF
---------face-config.xml
------WebContent
---------index.xhtml
When running the application of equinox, the bundle1 is the main bundle where all the browser requests are sent to. In the second bundle, the index.xhtml file can be retrieved the by first bundle upon request. The index.xhtml in bundle 2 gets its values and properties from the 'Bean.java' in bundle 2. The problem comes when i request the 'index.xhtml', the Bean.java class is not found. I think this is because the class loader of bundle1 cannot find it, it has no knowledge of it. So i would like to ask if anyone knows how to solve this problem. If so please do assist me, i have tried all the possibilities i had..
Is it in fact possible to have JSF run on multiple bundles using the same FaceletsContex? Can i be able to have seperate faces-config.xml files in each bundle, which can all be connected other faces-config.xml in other bundles? Can anyone please provide me a solution. Sample code would help.
If any one is interested in the answer, in this case, the faces-config.xml is of no use. So i had to use the plug-in.xml file to register all my beans across all plug-in projects. I created an extension point in the main plug-in, which other plug-ins could register their Beans as extension. I had to override the managedBean class of JSF for it to be able to read the bean properties from extension point rather than from the faces-config.xml.
So during runtime, the application reads all extensions registered in the managedBeans extension point, and then creates all the required bean instances from all plug-ins. Therefore the error will no longer be there. If anyone wants to implement JSF in such a structure, you should know that almost all the functionality in the faces-config.xml will have to be moved to the plug-in.xml of the plug-ins, this includes the navigation rules aswell. One has to do alot of customizations but at the end, you get a nice modular JSF application running on equinox, without having to embed it in a .WAR file.. which seems to be very advantageoous.
Related
I'm reviewing a current JSF project where the web.xml configuration contains:
the FacesServlet (configured on *.xhtml)
the com.sun.faces.config.ConfigureListener
I'm using JSF 2.2 and Mojarra implementation.
I'm confused about the ConfigureListener. Is this class needed in the configuration? What is the goal of this class? I couldn't find any information and the class has almost no javadoc.
If I remove this configuration, everything seem to work the same way. Thus I guess that the ConfigureListener could or should be removed but I am not sure.
The ConfigureListener is normally automatically registered via /META-INF/jsf_core.tld file of Mojarra implementation JAR file. Additionally, the ConfigureListener is explicitly registered via a Servlet 3.0 ServletContainerInitializer in order to workaround an old GlassFish v3 bug (note: v3, not 3.0.x, thus really that one first GF3 version ever).
There exist situations wherein the auto-registration via .tld file is insufficient. The well known one is when the webapp is deployed to Jetty. This is explained in detail in this Q&A: could not find Factory: javax.faces.context.FacesContextFactory.
Also, as mentioned before and in that detailed answer, GlassFish v3 has a bug wherein the TLD file is scanned too late and thus JSF couldn't do its necessary initialization thing at the right moment. You'd then need to explicitly register the ConfigureListener in webapp's web.xml.
But if it works for you when it's not explicitly registered in web.xml, then just keep it out. Less noise in web.xml is better. But if you happen to possibly deploy to a container sensitive to the mentioned problem (so when your webapp is actually a publicly distributed one and you have no control over choice of target container), then you'd better keep it in "for the case that".
Update: It appears that Tomcat 8.x shows buggy behavior when this entry is enabled in web.xml: this listener will actually be executed twice instead of only once. The consequence is disastrous: among others, all JSF event listeners will be registered twice and component libraries will be loaded twice. This leads only to conflicts during runtime. In other words, when deploying to Tomcat, make sure that this entry is removed from web.xml.
I'm using Websphere 8.5 and its internal Java EE frameworks, Apache OpenWebBeans for DI & Apache MyFaces for view. I also have a JAR with some beans annotated with "#Named" (so, they're OpenWebBeans managed beans). This JAR is in the "WEB-INF/lib" directory of my web application and in the application's classpath.
I was told that I should put a "beans.xml" file in every JAR that I want the CDI implementation to find and manage beans. I did just that (there's a "beans.xml" file in the "META-INF" folder of the application and in the same folder of the JAR) and everything works flawless in Tomcat 7 (I can access my beans on JSF pages, everything gets injected and resolved without any problems, etc). I'm running Tomcat with Apache Open Web Beans 1.2 and MyFaces 2.0 JARs inside the application's "WEB-INF/lib".
Now, the problem: in Websphere, with the same configuration (without the framework JARs inside the application's "WEB-INF/lib", just my bean's JAR) I get a NoClassDefFoundError referring to a JSF class, "javax.faces.component.behavior.Behavior" everytime I try to load a page (no page loads, btw). Bizarrely, when I remove all "beans.xml" files from the application and from the JAR, everything works as expected with JSF (except OpenWebBeans bean loading and management, of course, since there's no "beans.xml" present).
I searched everywhere for this problem and can't find any clue about it. I know that this class is avaliable to websphere, since I searched the server JARs and found it at "WEBSPHERE_INSTALL\plugins\javax.j2ee.jsf.jar" (and also because without the "beans.xml", this class is found and everything works properly), but I have no clue why this JAR isn't loaded when any"beans.xml" file is present in the application's classloader. Can somebody help, please?
WebSphere really needs a WEB-INF/beans.xml file in your WAR! Otherwise WAS doesn't 'activate' CDI. This is actually not required by the spec, bnd adding this file at least isn't forbidden. It will simply make all your classes in WEB-INF/classes CDI beans.
Just having the META-INF/beans.xml in some jars around doesn't help.
That's the way WAS works, it's a minor thing once you know it. I didn't even bother to create a PMR ;)
it's been a while now and still there are several things that are not clear to me.
Lets start with the basics: what I need to do.
I'm building a web application that manipulate some data, do some computation and give the user an output. There will be also a standalone version, with some simplifications.
So I thought this is the right time to use EAR packaging structure and EJB. I've created with netbeans a basic j2ee ear project with maven support:
All of them have their own pom.xml.
For what i understand, the first one is just a wrapper, the second one is the "real" project that doesn't contain source code, but encapsulate the other two.
In the web project I put all of the web stuff plus jsf backing beans. In the ejb one I was planning to put my data model with all the required annotations, and that comprehend also JPA and JAXB. There should be also some additional classes: a facade class, or session bean, that allow me basic data manipulation with the database, and some classes that contain my business logic strictly related to my data.
Question: is it correct to put all this things into an EJB project? Why not a simple project that the web module depends on?
Moving forward: the web project. First things is, netbeans doesn't put the EJB project dependency into its pom. So I can't see my beans from here. Is that correct or I have to manually add the SRA-ejb into the pom as a dependency?
Secondly, using some netbeans macro, like the ones that generate session beans from entity, or CRUD jsf pages from entities, it looks like he try to generate and put session beans here, in the web project. I think they fits better in the ejb one. What do you think?
One last question: in my stand alone application I was planning to use just the ejb module. But I think I have to carry with me an EJB container, am I right?
it's been a while now and still there are several things that are not
clear to me.
I know that feeling for sure :D
All of them have their own pom.xml. For what i understand, the first
one is just a wrapper, the second one is the "real" project that
doesn't contain source code, but encapsulate the other two.
Correct, it doesn't contain any sourcecode but can contain XML files for declarations and a common lib folder which contains shared libraries of the web and EJB projects.
In the web project I put all of the web stuff plus jsf backing beans.
In the ejb one I was planning to put my data model with all the
required annotations, and that comprehend also JPA and JAXB. There
should be also some additional classes: a facade class, or session
bean, that allow me basic data manipulation with the database, and
some classes that contain my business logic strictly related to my
data.
Question: is it correct to put all this things into an EJB project?
Why not a simple project that the web module depends on?
I don't know what you mean with a "simple project", if you mean just a plain JAR file with classes: an EJB module is nearly the same plus a deployment descriptor which invokes scanning of the annotations.
Moving forward: the web project. First things is, netbeans doesn't put
the EJB project dependency into its pom. So I can't see my beans from
here. Is that correct or I have to manually add the SRA-ejb into the
pom as a dependency?
Yes, in your case you need this dependency. You web project depends on your "service".
Secondly, using some netbeans macro, like the ones that generate
session beans from entity, or CRUD jsf pages from entities, it looks
like he try to generate and put session beans here, in the web
project. I think they fits better in the ejb one. What do you think?
I think it makes more sense to put them in the EJB project because they come from the javax.ejb.* package and belong to the EJB layer. You can put them in the we project, but then you don't really need an EAR and you can use a normal web project like you did before.
One last question: in my stand alone application I was planning to use
just the ejb module. But I think I have to carry with me an EJB
container, am I right?
No, you don't need an EJB container. You can lookup your EJBs via JNDI but you'll need an EJB with a remote interface and a copy of this interface in your standalone client.
You can find some tutorials about that here:
EJB invocations from a remote client using JNDI (JBoss)
How do I access a Remote EJB component from a stand-alone java client? (GlassFish)
GlassFish Project - Simple EJB 3.0 Stateless Session Bean Example
See also:
Maven2: Best practice for Enterprise Project (EAR file)
EAR package structure
Maven structure and Java EE applications
My scenario is this:
I have a template with some base code for my application. This template has some custom renderers and some beans in the faces-config.xml file.
Then I have my application that inherits the base code from the template and this application has some additional beans. And everytime I refresh from the template I need to manually add the "local" application beans into faces-config.xml.
Is there a way to have multiple faces-config.xml files or is there another way to fix this problem?
This sounds like a perfect use case for an OSGi plugin: shared features applied to an application that, in turn, has its own custom behavior. An XSP Library supports multiple faces-config files because there's an explicit method for declaring which files to load. An NSF, on the other hand, assumes it contributes only one of its own.
JSF 1.1 and websphere 6.1 was working properly in my case. Once I deployed that to a websphere 7 server, I received the following error -
Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactoryat javax.faces.FactoryFinder.getFactory(FactoryFinder.java:270)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:164)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:358)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init(ServletWrapperImpl.java:168)
Not sure what it means, I have enabled JSF1.2 as project facet in the RAD but still keep getting the above error message and none of my jsf files are working.
EDIT
After following BalusC's comment, I see the following directories are lookup by the code (this is the o/p of url.getPath())
/C:/IBM/SDP/runtimes/base_v7/profiles/AppSrv01/properties/
/C:/IBM/SDP/runtimes/base_v7/properties/
/
/C:/IBM/SDP/runtimes/base_v7/java/lib/
/C:/IBM/SDP/runtimes/base_v7/lib/
/C:/IBM/SDP/runtimes/base_v7/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime/
/C:/IBM/SDP/runtimes/base_v7/installedConnectors/sib.api.jmsra.rar/
/C:/IBM/SDP/runtimes/base_v7/installedConnectors/wmq.jmsra.rar/
/C:/DETSphere10/DET_FALL9.0/DETEJB/classes/
/C:/DETSphere10/DET_FALL9.0/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/DETWEB/
There is no jsf impl in among these directories. Now I am more confused as the original lib should be present under c:\IBM\SDP\runtimes\base_v7\plugins !!
This is a typical error when there are multiple different versioned JSF libraries in the classpath. Websphere ships with builtin JSF libraries. If you'd like to use the webapp-supplied JSF libraries, then you need to set the classloading policy to module after deploying. This usually defaults to application which means that the webapp libraries are loaded by the main classloader. The main classloader may happen to have loaded the JSF API library. When its version is different from the JSF IMPL library in the webapp, then you may receive this kind of errors.
Update to help with nailing down the root cause better here are 2 suggestions:
You can reveal all used classpath roots on the local disk file system as follows:
for (URL url : Collections.list(Thread.currentThread().getContextClassLoader().getResources(""))) {
System.out.println(url.getPath());
}
Execute this in ServletContextListener#contextInitialized() or so.
(eventually after finding that out), install WinRAR, associate it with JAR file type and use its file-search facility to search for a JSF specific file like FacesContext.class and FacesContextImpl.class so that you can find all JAR's which contains the JSF API/impl. You can find out the exact JSF version by extracting the JAR and reading the MANIFEST file.
You need to keep the JSF JAR's (icu4j.jar and jsf-ibm.jar if you are using IBM's component library) in your /WEB-INF/lib folder.