My Maven EAR project has two WAR module and one EJB module. There is a FacesConverter class in EJB module and when I try to use it from one of the WAR module it throws an exception. I register this converter with annotation #FacesConverter("org.util.ObjectConverter") use it in a JSF page
javax.servlet.ServletException: Expression Error: Named Object: org.util.ObjectConverter not found.
When ObjectConverter is in WAR module it works fine, but it won't load from the EJB module.
What am I missing here?
Cheers
Why do you put it in EJB module? Front-end (read: JSF) artifacts should go in WAR module. EJB module should only contain business services which are supposed to be reuseable to front-ends other than JSF, such as JSP/Servlet, Struts2, SpringMVC, JAX-RS, etc. The EJB module should absolutely have no single line of javax.faces.* import/dependency in the code.
JSF doesn't look for converters (let alone any other JSF related artifacts such as validators, managed beans and Facelets files) in EJB module, but only in WAR module. Just keep them in the WAR module. Whatever code you think need to share between the WAR and EJB modules should be refactored into a separate Java project which end up as a common JAR file in EAR module (note that this should in turn also contain no JSF-specific artifacts.
Related
I've an EAR with an EJB and WAR project in it. I use Netbeans and the Maven building tool. In my EJB there is one EJB, a singleton class: http://pastebin.com/f8jXw0TK
Here is a screenshot of my project structure in Netbeans: https://gyazo.com/09e075972279f637de2d4d98fe9a1ac7
When I deploy the EAR or the EJB-JAR in Glassfish (localhost). I get the follow error message:
Error occurred during deployment: Exception while deploying the app [arp-auth-business-1.0] : Invalid ejb jar [arp-auth-business-1.0]: it contains zero ejb. Note: 1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or message-driven bean. 2. EJB3+ entity beans (#Entity) are POJOs and please package them as library jar. 3. If the jar file contains valid EJBs which are annotated with EJB component level annotations (#Stateless, #Stateful, #MessageDriven, #Singleton), please check server.log to see whether the annotations were processed properly.. Please see server.log for more details.
I've added a simple stateless bean to the EJB JAR, and then it deployed. But then I saw just the simple stateless bean I created, but not my singleton class.
What could be wrong? The server.log shows the same error I get in Glassfish but with a exception stack from the loader. No error from the singleton class or something like that...
Still trying but can't figure it out. Maybe it's maven? But the jar and war file are in the ear file. And in the jar file there is my singleton class.
Kind regards
Working with GlassFish, trying to be tidy, I would like to put all of my business logic into a single EJB JAR. I then have 2 WAR files.
app-frontend-war
app-backend-war
app-logic-ejb
Each of the WAR files need to use the EJBs that are within the app-logic-ejb JAR. This EJB JAR holds the main persistence unit. But I am finding that #Inject of any app-logic-ejb EJB's from any Java within the WAR files are not working.
Also, I am trying to avoid using an EAR.
With the help of the Java EE 7 tutorial I have finally worked it out.
Even though the beans in app-logic-ejb are on the same GlassFish they need to be annotated as remote beans. The WAR files then use #EJB injection (instead of #Inject) into the correct interface within the WAR file.
#EJB
TestBeanInterface t;
To share the interface between the EJB JAR and the War files a Java Library is needed.
So to make it work it turns out I need:
app-library
app-logic-ejb
app-frontend-war
app-backend-war
Are there any differences in capabilities of the EJB when defining / running it from a WAR vs. an EJB container? What are the benefits vs. drawbacks of deciding on one approach vs. other.
What capabilities do we lose when accessing it from a WAR?
In our case, the developers want to use the EJB for creating / accessing REST webservice.
One of our architects has mentioned below. And for this reason he wants to have a separate EJB that would be added ( the jar ) to EAR but also to WAR for using it as REST endpoint. i would prefer not to have it in multiple places
I’d prefer our approach to put transaction/service based code in EJBs to
leverage Container Managed Transactions, JPA, MDB and all the good stuff EJBs
have to offer.
From the documentation I have read on using EJB as a REST service implementation, it says
Add the EJB class to the WEB-INF/classes directory of your WAR file or to a
JAR that is located in your WEB-INF/lib directory. When a client makes a request
to a JAX-RS annotated enterprise bean, the JAX-RS runtime environment looks up
and uses an EJB instance of the class to invoke the resource method.
So, I want to know, if we put the EJB in the WAR - as in creating the source in the WAR's source so that the class will be added to WEB-INF/classes when the WAR is built, instead of having to put the same ejb jar in two different places based on what it is used for - as a REST webservice endpoint vs. other capabilities, will it satisfy all the requirements or I will have to put the jar in two places?
I am using Websphere 8.5 with EJB 3.1, if that makes a difference in the answer.
There are two primary differences highlighted in section 15.4 of the EJB 3.1 specification:
All EJBs in a WAR share the component namespace (java:comp) with the WAR and all other EJBs in the WAR. Normally, each EJB has its own component namespace. This makes it easier to share reference names and bindings (though this can be done explicitly in EE 6 with java:module or java:app), but it increases the chance of conflict in a large WAR.
EJB classes are loaded by the WAR class loader. In practice, this doesn't matter much, it's just something to be aware of if you encounter class loading problems.
If you want to use an EJB as a REST service, you must package the EJB in the WAR. If you're concerned about "duplicating" EJB logic inside the WAR and for an EJB module, you could declare a base class in the EJB module, and then declare subclasses in the WAR and EJB modules that extend the base class and are annotated #Stateless or #Singleton.
Regarding EJB capabilities there is no difference between packaging an EJB in a WAR or in an EJB module.
There are situations where you have to package EJBs in WARs e.g. if you have a REST endpoint which is at the same time an EJB.
Most often WARs encapsulate frontend functionality. In these situations it is just from a design perspective not advisable to put the EJBs into WARs.
I am working on a webapp which uses Primefaces as a view, and I inject Spring beans from other projects into JSF Managed beans.
I have an architectural problem:
I've created separate projects(modules) for each component that I use (Business Logic, Persistence, and others) and also create separate projects with their interfaces.
I want my webApp to depend only on the interface of the Business Logic, and to inject the implementation of the BL using Spring Dependency Injection.
I want to achive this recursively: Business logic to depend only on other interfaces, and to inject implementations using spring.
The problem is that having no dependency in the Maven pom file to the actual implementations, when I deploy the application (on a web logic server) the implementation jars are not deployed, and Spring doesn't find the beans to wire.
Is there a way to achieve decoupling without adding dependencies to actual implementations?
Can I include Spring's bean configuration files from other projects if the projects are not added as dependencies?
Did I figured this decoupling all wrong?
I appreciate your ideas.
Well obviously you need the dependencies in your maven pom else nothing will be included. You can add the dependencies with a scope of runtime which includes them in your final war but not during development (scope compile).
For loading the context of modules you might come-up with a naming convention and/or standard location for your files. With that you could do something like this in your web applications beans xml
<import resource="classpath*:/META-INF/spring/*-context.xml" />
This would load all files ending with -context.xml from the /META-INF/spring directory on the classpath (including jar files).
I have a class in a war...
SomeClass.java
This class is embedded into a war which is embedded in an ear. Also, embedded in the ear is an EJB class which references a class in the war (not my design). This class clearly exists and I can see it in the deployed WS app. The ear file looks as follows...
ear file
META-INF
war file <Where the .class is found>
ejb jar file
But I still get a ClassNotFound Exception on SomeClass can anyone think of what I am missing? This is pretty old versions so do I have to set the classpath in the META-INF in the ejb jar even if the jar is in the exploded war?
Thanks
OMG this is REALLY messy. Glad it's not your design. As you know EJB classes should NEVER depends on libs or classes from war files. That said if you need that your class "SomeClass.java" to be available to both, the war and ejb.jar package, than you should build a third standard.jar file with the class in it and place it under ear/lib folder of your package. This should make the class available to both packages, the .war and .jar(ejb) files.
Since you are using WebSphere, you may want to try setting the WAR class loader policy to "Application", as described in the following document:
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.express.doc/info/exp/ae/crun_classload.html
This would create a single class loader for the entire application, i.e. the EJBs and the classes in the WAR would be loaded by the same class loader. This should solve your problem.
Create a lib folder under the EAR file structure and copy all the jar fiels which you want to use as common for both WAR and EJB in it. This should solve the problem.