Is there a way to perform a communication between WARs within an EAR deployment archive in such a way that it would be possible not just to make usage of JSF Managed Beans (annotated as #ManagedBean or #Named) as well as Facelets resources from one WAR to another and vice-versa?
The JEE container used is the Wildfly 12.
Our project's structure is similar to the following one:
EAR
A.war
B.war
ejb.jar
I've read some articles mentioning the shared session configuration inside jboss-all.xml file descriptor.
Some other articles suggests the ear-subdeployments-isolated usage set to false in the jboss-deployment-structure.xml file descriptor.
Are there other ways to achieve that rather than the suggestions above? More over, is that possible to achieve such communication?
Thanks.
Related
The project artifact structure is:
test.ear
--lib - has all log4j2 jars core, web, bridge and JCL
--META-INF -- has app.xml, JBoss specific deployment XML, and manifest file
--a.war -- each war has web.xml with log4jConfiguration and Log4jServletContextListener specified.
--b.war
--c.war
The war creates context with log4jConfiguration, which is "classpath:test.xml". I can see each war creating the context with log4jContextName I have provided in web.xml.I have a few crons, too, which run based on configured time intervals. When crons run, and many of the JMS process run, I observed the log files are not populated with logs(From project-specific classes). While going through the log4j2 code, I understood that log4j2 creates a context for each classloader. And in my case, it creates a context for "test.ear", which is defaulted to error(DefaultContext) as it is not able to find a default log4j2.xml since I have a custom named(test.xml) on in the classpath. The Log4jServletContextListener does not catch the "test.ear" event.
How to inject my "classpath:test.xml" while log4j2 creates a context for the ear file? Since my project can be both deployed to WebSphere and JBoss, I am looking forward to suggestions that are not server-specific. Or is there a way to create a single context for all the war and ear somehow? I have different apps outside this ear in same server so I cannot give an environmental config of -Dlog4j.configurationFile as other apps have there own log4j2 xml's.
One approach that I can think of is to place your log4j config file test.xml in a shared library and configure your application to use the shared library.
The following link describes how to configure a shared library for a server or an enterprise application on WebSphere.
https://www.ibm.com/support/pages/how-create-shared-library-and-associate-it-application-server-or-enterprise-application-websphere-application-server
The shared library should be a generic function for modern Java app servers, so JBoss should also be able to configure this.
I'm afraid this question might not be as "close ended" as a StackOverflow question should be. Hopefully, I'm wrong.
Context
We have a project (the typical Java EE with a JSF web GUI) that, due to requirement's specificities, we needed to split in two projets. One of these new split projects is a subset of the previous, with some slight differences.
So, from ORIGINAL_JAVAEE_WEBAPP.war we created: ORIGINAL_JAVAEE_WEBAPP-Proj01.war and ORIGINAL_JAVAEE_WEBAPP-Proj02.war.
In order to avoid redundancy we've decide to create a JAR file with all the facelets, managed beans and related pojos. The idea was that each WAR would include this JAR, use whatever they need and, then, the WAR would have the specific pages, logos, ...
The problem
I've created a simple example just to practice having a JAR file with facelets and having two WAR files including and using these facelets. In this example, things worked flawlessly.
Nevertheless, "the real world" is not that simple. Our project also relies on Primefaces, Spring Core and Spring Security, just to mention a few.
The implementation is not yet finished - far from it. Right now, under the same Maven project, I've created the JAR module, moved the beans and the facelets to that module and included it as a dependency in the WAR file module.
The problem is that, now, my "FacesContext.getViewRoot().getViewId()" tells me that viewId is "someName.jsp" and not "someName.jsf". This simple change messes up with our "legacy" "authentication phase listener" (a phase listener to ensure that a user is logged in and redirect accordingly) implementation.
So, what can be happening here? Do any of you have any hint of what my next steps might be in order to track the root source of this problem?
Thanks and regards.
This could be an issue with the JSF ViewHandlers registered for the FacesContext. What version of JSF are you using and are there any view handlers defined in the JSF context xml.
Also please check in the web.xml the context params :javax.faces.DEFAULT_SUFFIX, javax.faces.FACELETS_VIEW_MAPPING
I am working on a large scale system using PrimeFaces 5.0, Java EE 7, Maven 3.0.5, Netbeans 7.4 & GlassFish 4.0
I want to implement it as (multiple WARs , multiple EJBs , one EAR).
Multiple wars could have common files like (JS, CSS, XHTML, Backbeans & Converters)
i have achieved this using jar which contains this resources.
different WAR files, shared resources
I need a session-scoped bean to be shared between different wars, I found this but i found it more than what i need.
http://docs.oracle.com/cd/E18686_01/coh.37/e18690/glassfish.htm#CEGBDHJB
so my questions is:
Is using a jar is the right approach to share what i want ??
where do i put jars like primefaces or omnifaces in the project where they use the same class loader ??
How can i share session-scoped between different wars ??
I have been working on a ear project with similar requirements as yours, according to our experience :
Sure. We have seperated our war projects and use them as extended controllers to carry out front end logic and passing data to view, and they make their service calls via a jar file called common-services.jar . Our whole service layer is living on a single jar file. However if you ask my personal opinion, I think it would have made a lot sense to create a third war file just for the services, and talk restful with all the front-end repos. That way service calls could be opened to third party users without any further work. So to sum it all up, yes it is an acceptable approach, but you should also consider packing it as war.
On a parent pom above all war, so all war files use the same version and it is managed from a single pom.
Carry all session based operations to your third jar / war we have discussed in question 1. Makes much more sense that way. Or I suppose you will need solutions like single sign on. But my first suggestion works like a charm for us.
We are planning on migrating our legacy Java EE application from an ant build to a maven build. Currently, each of our EJBs has its own META-INF/ejb-jar.xml.
Maven only expects one ejb-jar.xml per EJB module. So when I build none of these EJBs are identified as needing to go through ejbc.
I'd really prefer not to have to combine all of these ejb-jar.xml's (and also weblogic specific .xml's) down into a single descriptor as there are > 50 and this would cause a hot mess. I also don't want to break down each of these EJBs down into separate EJB modules as this is also going to cause a small nightmare.
Question: Does anyone know a (hopefully elegant) way to still have maven build all my EJBs with their own ejb-jar.xml other than the two (not elegant) ways above?
We ended up just merging them down into a single descriptor manually. This avoided any weird ant task like solutions as well as shattering the project into hundreds of pieces. The goal will be to migrate as many beans to EJB 3.0 annotated style as possible as they are touched.
Ran into an interesting issue too where EJB 2.0 ejb-jar.xml caused annotations not to fire. Simply fixed by updating the now merged descriptor to 3.0. This exposed on single change on the DTD side having to do with MDBs that was easily fixed with some regular expression replace magic.
We have a very comfortable setup using JPA through Spring/Hibernate, where we attach a PersistenceUnitPostProcessor to our entity manager factory, and this post processor takes a list of project names, scans the classpath for jars that contain that name, and adds those jar files for scanning for entities to the persistence unit, this is much more convenient than specifying in persistence.xml since it can take partial names and we added facilities for detecting the different classpath configurations when we are running in a war, a unit test, an ear, etc.
Now, we are trying to replace Spring with Seam, and I cant find a facility to accomplish the same hooking mechanism. One Solution is to try and hook Seam through Spring, but this solution has other short-comings on our environment. So my question is: Can someone point me to such a facility in Seam if exists, or at least where in the code I should be looking if I am planning to patch Seam?
Thanks.
If you're running in a Java EE container like JBoss 6 (and I really recommend so), all you need is to package your beans into a jar, place a META-INF/persistence.xml inside it and place the jar into your WAR or EAR package. All #Entity annotated beans inside the jar will be processed.
For unit-testing, you could point the <jar-file> element to the generated .class output directory and Hibernate will also pick the Entities. Or even configure during runtime using Ejb3Configuration.addAnnotatedClass;
#see http://docs.jboss.org/hibernate/entitymanager/3.6/reference/en/html/configuration.html