I have an EJB X implementing interface IX; I have a web service Z deploying in WebSphere; one of its classes declares the following:
#EJB
IX ix;
When X and IX were in the same source tree as the application, this worked fine. I had it as #Singleton and #Startup, though I've sinced changed it to #Stateful.
The application has a jar it shares with another web service, and this 2nd web service can also make use of X. So I want to move X to a jar (or whatever) used by each web service.
There is a jar currently used by both web services, so I moved X, IX and another dependent class to the source tree for that jar. I compiled the jar and exported it, overwriting the jar previously used. I've opened that and verified that the three new classes are in it.
When I run the app in the server (RAD/eclipse) I get an error message:
com.ibm.ejs.container.EJBNotFoundException: EJB with interface IX not present in application Z.
As stated above, I have this declared as #EJB in a class in the application, in a place that works when IX and its supporting classes are in the same source tree.
The RAD/eclipse project for the jar file did not originally have an EJB facet, so I added that; I recompiled and etc., get the same error. I can add things to ejb-jar.xml if needed, though I thought that's what the Annotations were for. But maybe there's something the annotations don't do, or that I need to add something for, now that the bean is in a different jar.
I figure I've missed something about configuring or declaring this. Is this enough information to tell me what it is?
EJB X must be in EJB jar, not utility jar for annotations to work. Put only interface IX in utility jar, and make all other projects - EJB, WS1 and WS2 - dependent on that jar (add jar to EAR/lib for example). Pack all projects in EAR.
Related
I currently have the following project structure
EAR
|---myapp1.war
|---myapp2.war
|---myapp-ejb.jar
I would like to get rid of the ear and deploy myapp1 and myapp2 on their own. I tried to make myapp-ejb.jar a maven dependency of the two war and everything works fine at compile time. Nevertheless, there are a lot of jndi lookups in the code that fail at deploy time. Is there a way to make this to work?
Theoretically, it is possible to have ejb in a web archive (war).
Although not necessary, you could try to put a 'ejb-jar.xml' file (located in the WAR module’s WEB-INF) to replace the normal auto-discovery mechanism ?
Be also aware that the WAR file must be version 2.5 or later to contain EJB content.
Extract the WAR from the EAR
Scope ejbs as "provided" per https://stackoverflow.com/a/42847318/8528208
Place the ejb.jar in your WAR's WEB-INF/lib per https://stackoverflow.com/a/6968674/8528208
Further documentation at https://www.ibm.com/docs/en/was/8.5.5?topic=modules-ejb-content-in-war
--
Archived edits comments refer to:
Update-
Is the ejb.jar in the build class path of your .war? If your project is maven based, is the ejb.jar a dependency of the .war project? If so, try adding the EJB module as a "provided" dependency per https://stackoverflow.com/a/42847318/8528208
--
"An .ear file is a collection of entities (i.e., .war files), so you can simply extract the .war file from the .ear file and deploy it."
-per https://stackoverflow.com/a/26658071
If this doesn't help, can you add a lookup attribute in your #EJB annotations such as
#EJB(lookup="java:global/mwf_ejb/UserManager")
Similar to this answer?
https://stackoverflow.com/a/10156279/8528208
I'm writing an answer to my own question, since I solved the issue. It is perfectly fine to use EJBs with a WAR only (no EAR) as stated here https://docs.oracle.com/cd/E19798-01/821-1841/gippi/index.html.
As for the lookups calls, the correct way to do it is described here https://docs.oracle.com/cd/E19798-01/821-1841/girgn/index.html.
The issue I was facing wasn't really related to the lookups, as I was thinking, but it was due to the way most of the EJBs were initialized.
I noticed that in most of the classes there was some nasty initialization code like the following:
#Stateless
public class FooResource
{
FooEjb fooEjb = lookupFooEjb();
private FooEjb lookupFooEjb()
{
javax.naming.Context c = new InitialContext();
return (FooEjb) c.lookup("java:global/FooApplication/FooModule/FooEJB!FooInterface");
}
}
This works fine with the EAR because the EJB module is loaded before the WAR archives, so the lookups do not fail.
My guess is that when you package the EJBs with the WAR, it loads the EJBs as they are needed, computing the dependencies based on the #EJB annotation, so that kind of initialization fails since the EJB might be not loaded yet. To make it work, I just removed the lookup and added the annotation #EJB.
#Stateless
public class FooResource
{
#EJB
FooEjb fooEjb;
}
I developer a web application using Java. When I deploy it to my application server (Jetty, Tomcat, JBoss, GlassFish, etc.) throws an error. I can see this error message in the stacktrace:
java.lang.ClassNotFoundException
Or
java.lang.NoClassDefFoundError
What does this mean and how can I fix it?
What does this mean?
First, let's see the meaning of java.lang.ClassNotFoundException:
Thrown when an application tries to load in a class through its string name using:
The forName method in class Class.
The findSystemClass method in class ClassLoader.
The loadClass method in class ClassLoader.
but no definition for the class with the specified name could be found.
Usually, this happens when trying to open a connection manually in this form:
String jdbcDriver = "...'; //name of your driver
Class.forName(jdbcDriver);
Or when you refer to a class that belongs to an external library and strangely this class cannot be loaded when the application server tries to deploy the application.
Let's see the meaning of java.lang.NoClassDefFoundError (emphasis mine):
Thrown if the Java Virtual Machine or a ClassLoader instance tries to load in the definition of a class (as part of a normal method call or as part of creating a new instance using the new expression) and no definition of the class could be found.
The searched-for class definition existed when the currently executing class was compiled, but the definition can no longer be found.
The last part says it all: the class existed at compile time i.e. when I compiled the application through my IDE, but it is not available at runtime i.e. when the application is deployed.
how can I fix it?
In Java web applications, all third party libraries used by your application must go in WEB-INF/lib folder. Make sure that all the necessary libraries (jars) are placed there. You can check this easily:
- <webapp folder>
- WEB-INF
- lib
+ jar1
+ jar2
+ ...
- META-INF
- <rest of your folders>
This problem usually arises for JDBC connectivity jars (MySQL, Derby, MSSQL, Oracle, etc.) or web MVC frameworks libraries like JSF or Spring MVC.
Take into account that some third party libraries rely on other third party libraries, so you have to add all of them in WEB-INF/lib in order to make the application work. A good example of this is RichFaces 4 libraries, where you have to download and add the external libraries manually.
Note for Maven users: you should not experience these problems unless you have set the libraries as provided, test or system. If set to provided, you're responsible to add the libraries somewhere in the classpath. You can find more info about the dependency scopes here: Introduction to the Dependency Mechanism
In case the library must be shared among several applications that will be deployed on your application server e.g. MySQL connector for two applications, there's another alternative. Instead of deploying two war files each with their own MySQL connector library, place this library in the common library folder of the server application, this will enable the library to be in the classpath of all the deployed applications.
This folder vary from application server.
Tomcat 7/8: <tomcat_home>/lib
JBoss 7/Wildfly: <jboss_home>/standalone/lib
The class must exist under WEB-INF/classes or be inside a .jar file under WEB-INF/lib. Make sure it does.
Same problem happen with me.
Might be possible one of your libraries are using some classes internal which is not available
in your lib or maven dependency pom.xml.
Thats means you have analyze your error logs and identify these classes and then import all dependencies in maven or lib folder.
I have fixed this error by the same way.
because some of my libraries are using activation.jar and json.jar internally.
Consider the following: support.jar
public class SupportUtil{
private static Map<String, Resource> myResources;
void init(){
initResources();
}
}
Then i have 2 independent war applications conneting remotely to another ejb module within the same javaee server (currently using wildfly 8)
war1 -> lib/support.jar
war2 -> lib/support.jar
ejb1 -> ear-lib/support.jar
My questions is, based on module classloading architecture, would the three modules see the same Map off myResources (considering that this is a class variable, and class variables are shared by all instances)
I need clarification, for wildfly or glassfish, how classloading would affect this behaviour.
The war is considered to be a single module, so classes defined in WEB-INF/lib are treated the same as classes in WEB-INF/classes. All classes packaged in the war will be loaded with the same class loader.
By default the EAR/lib directory is a single module, and every WAR or EJB jar deployment is also a separate module.
Each module will load its own class instance with its own static field values.
Sub deployments (wars and ejb-jars) always have a dependency on the parent module, which gives them access to classes in EAR/lib, however they do not always have an automatic dependency on each other. This behaviour is controlled via the ear-subdeployments-isolated setting in the ee subsystem configuration.
WARs usually depend on EAR/lib. So your WAR modules would "see" two instances of SupportUtil. When the code executes in the WAR module context (during a web application request), it would see it's own lib instance of SupportUtil. When you WAR calls EJB remotely (or even locally!) then the module context switches to EJB, and the "current" instance of SupportUtil comes from the EAR/lib module. (Disclaimer: I didn't test this, but that's my understanding.)
I wouldn't advise getting into this position, when a module has access to multiple instances of the same class. I don't have any failure stories to back that up, it just seems to be a potential source of confusion: a code in the same module can see different values depending on how the execution got there.
There is a special case though.
The ear-subdeployments-isolated element value has no effect on the isolated classloader of the .war file(s). i.e. irrespective of whether this flag is set to true or false, the .war within a .ear will have a isolated classloader and other sub-deployments within that .ear will not be able to access classes from that .war. This is as per spec.
WARs are always isolated! So you could have the same jars/classes in multiple WARs, and no module will see more multiple instances of the same classes.
Source: Class Loading in WildFly.
I have two war file app1.war and app2.war deployed in a single JBoss instance. Package names for java classes for both war files starts with com.myapp
To add further, there are some Classes that are common between the two apps while there are some that have same fully qualified class names but are different (Source Code has changed).
I want to know, if this could pose threat of any kind to the deployment scenario?
You could get class loading problems if your applications are not isolated, i.e. have their own class loading repository and class loaders. If you configure JBoss to isolate the applications from each other you should be fine (I don't know what is the default for your version but 4.2.3 that we use does not isolate apps by default).
To clarify that a bit:
If you have two classes with different implementations but the same FQCN you could get the wrong class from the class loader for the application that is loaded second. Even if the implementation was the same you could get class cast exceptions or other strange behavior if one app gets the class from the other app.
I had a similar situation with multiple apps.Look at my solution here
Best way is to isolate class loading for your application archives.
For JBoss 5.1.0 GA following worked for me.
Create jboss-classloading.xml file in WEB-INF folder.
Added following lines to this file
Here,
export-all="NON_EMPTY" => Makes sure the classes loaded for this app is not exported
import-all="true" => Imports and uses all of the class definition available.
parent-first="false" => If more than one class with same name is found, one defined under the application will be used first.
FYI. This also helped me embedding the log configuration of log4j in the application war file. Will need to place log4j.xml in WEB-INF/classes and have a log4j.jar in WEB-INF/lib folder.
There will be one class loader instance for each application or standalone module. In other words, classes in app1.war will be loaded in different class loader than the classes in app2.war. This is the default behavior of any Java EE server; So it really doesn't matter about having classes with the same package/names and/or different content. This is the default behavior of any Java EE server.
Having said that, if you tweak the class loader policy of the server or try to load classes (reflect) using anything other than Thread.currentThread().getContextClassLoader(), you could be asking for trouble.
If I have classes that need to be shared between my webapp and Tomcat (e.g. a custom realm and principal), where should the .jar file containing those classes go?
Currently I'm putting the .jar in ${CATALINA_HOME}/lib. This result is a ClassCastException when assigning references from classes of the same type. Here's an example:
MyCustomPrincipal principal = (MyCustomPrincipal)FacesContext.getCurrentInstance().getExternalContext().getUserPrincipal();
The method above throws a ClassCastException. The method returns an actual MyCustomPrincipal type (since that's what my custom realm gave Tomcat when it performed authentication) that, apparently, was created by a different classloader. How do I fix this so both Tomcat and my webapp can use MyCustomPrincipal?
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
Any help is appreciated.
Andrew
It looks like you have 2 copies loaded, once in tomcat and once in your WEB-INF/lib jars or other classpath of your deployed application.
The reason you get classpath exception lies in the way a WAR looks for classes. Contrary to the normal Java rules, a war first looks inside the war for a class and only then passes the request to teh parent classloader.
A class's identity is dependent of the classloader and the same class loaded in 1 classloader will generate a classcast exception when it is casted in the other classloader.
The solution is to make sure that the war does not contain the classes which should be provided by the container. If you use maven you can mark these dependencies as 'provided', if you use ant, you have to split your classpath list in 2 and compile against both, but use only the ones you need for constructing the war.