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.
Related
I know that spring boot packages an executable jar with spring-boot-loader and loads other jars from BOOT-INF/lib as described in this post, using a class named JarLauncher.
After reading this post, I was thinking that Class-Path in manifest can do this, too.
So why does spring boot do so many works to load jars from a customed BOOT-INF/lib, rather than just write simply in META-INF/MANIFEST.MF:
Class-Path: BOOT-INF/lib
The Class-Path manifest approach does not support loading classes from jar files nested within a jar. From the Oracle documentation that you've linked to in your question:
The Class-Path header points to classes or JAR files on the local network, not JAR files within the JAR file or classes accessible over Internet protocols. To load classes in JAR files within a JAR file into the class path, you must write custom code to load those classes. For example, if MyJar.jar contains another JAR file called MyUtils.jar, you cannot use the Class-Path header in MyJar.jar's manifest to load classes in MyUtils.jar into the class path.
Spring Boot's JarLauncher and the other classes in spring-boot-loader are the custom code that allow classes to be loaded from jars nested within a jar.
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
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.
How can I add jars to the "Utility JARs" folder in websphere. If the required jar is already contained within the lib dir of a war which is contained in the ear, is the jar still required in the "Utility JARs" folder ?
Utility Jars typically contain classes that are used by multiple modules in an EAR. It does not make sense to keep multiple copies of those classes. For e.g. you have a Servlet and an EJB in an EAR using a shared Class. This shared class can be kept in a JAR (and placed as a utility Jar to the EAR).
Now it becomes available to both the servlet and EJB which are present in the EAR,
Utility jars are applicable to both a WAS based Java EE application and also a WPS based integration/bpel centric applications. I am guessing it is a WAS based Java EE application.
Refer to:
http://www.ibm.com/developerworks/websphere/library/techarticles/0304_manji/manji.html
This is very old but the concept hasn't really changed all these years.
To specifically answer your question, if there is only WAR file in your EAR then there is no advantage of using the Utility JAR.
If you have multiple WARs in an EAR sharing classes, those shared classes are good candidates for a utility Jar
Hope this helps
Manglu
I'm looking for some kind of "best practice" informations about Spring jar configuration. I have a web project (war) and I need connect some jar libraries - my jars which contains additional functions. These jars contains Spring services. But when I connect jar, the service class did not work, because Spring don't know about that. So I need to tell Spring about this by “package auto scan” configuration inside my jar.
The final solution must be war project (main functions) and some additional jars which contains other functions. When I add jar into war project, I don't want to change configuration in applicationContext.xml (in war). I want minimal dependency to war project. I was thinking, when if I place applicationContext.xml to META-INF folder in jar it will be auto loaded by Spring, but it is not.
Do you know how can i solve this? May be some kind of “after startup dynamic configuration” :-). thanx
If you are trying to load annotated beans from the jars into your war's Spring context, you can set up a component scan in the war's context xml file to scan the packages in the jars.
If you are trying to load beans defined in XML files from the jars, you can include them using something like this in your war's Spring context xml file:
<import resource="classpath:path/to/config/in/jar/beans-from-jar.xml"/>
You shouldn't need to have your jar know anything about your war this way. You just scan the annotated beans and/or import the config from the jar.