When I deploy an exploded war file datanucleus fails with following error
Caused by: org.datanucleus.exceptions.ClassNotResolvedException: Class "JDOTutorial.war.WEB-INF.classes.com.blogspot.jkook.daytrader.jdo.QJDOOrderData" was not found in the CLASSPATH
This does not occur when war is deployed. Seems DN is scanning for classes which use JDO annotations when loading the JCA. With exploded deployment it is scanning all the classes inside the exploded folder and fails to load since the location of the class and the class in the class path does't match. (class name is com.blogspot.jkook.daytrader.jdo.QJDOOrderData , but DN is looking for
JDOTutorial.war.WEB-INF.classes.com.blogspot.jkook.daytrader.jdo.QJDOOrderData)
I am using settings below but DN is still scanning the exploded folder
datanucleus.autoStartMechanism = Classes ,
datanucleus.autoStartClassNames = com.blogspot.jkook.daytrader.jdo.JDOOrderData
Question : How to hint DN to stop scanning the exploded folders ?
finally solved jboss has feature to add external deployment folder
default = deployment -- placed the datanucleus-jca-3.0.0-m6
myPath = extdeployments -- placed the JDOTutorial.war (exploded folder)
Now DN doest scan for classes inside exploder folder :)
Related
I'm trying to create app based on Jetty 9.4.20 (embedded) and Vaadin Flow 14.0.12.
It based on very nice project vaadin14-embedded-jetty.
I want to package app with one main-jar and all dependency libs must be in folder 'libs' near main-jar.
I remove maven-assembly-plugin, instead use maven-dependency-plugin and maven-jar-plugin. In maven-dependency-plugin i add section <execution>get-dependencies</execution> where i unpack directories META-INF/resources/,META-INF/services/ from Vaadin Flow libs to the result JAR.
In this case app work fine. But if i comment section <execution>get-dependencies</execution> then result package didn't contain that directories and app didn't work.
It just cannot give some static files from Vaadin Flow libs.
This error occurs only if i launch packaged app with ...
$ java -jar vaadin14-embedded-jetty-1.0-SNAPSHOT.jar
... but from Intellij Idea it launch correctly.
There was an opinion that is Jetty staring with wrong ClassLoader and cannot maintain requests to static files in Jar-libs.
The META-INF/services/ files MUST be maintained from the Jetty libs.
That's important for Jetty to use java.util.ServiceLoader.
If you are merging contents of JAR files into a single JAR file, that's called a "uber jar".
There are many techniques to do this, but if you are using maven-assembly-plugin or maven-dependency-plugin to build this "uber jar" then you will not be merging critical files that have the same name across multiple JAR files.
Consider using maven-shade-plugin and it's associated Resource Transformers to properly merge these files.
http://maven.apache.org/plugins/maven-shade-plugin/
http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html
The ServicesResourceTransformer is the one that merges META-INF/services/ files, use it.
As for static content, that works fine, but you have to setup your Base Resource properly.
Looking at your source, you do the following ...
final URI webRootUri = ManualJetty.class.getResource("/webapp/").toURI();
final WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));
That won't work reliably in 100% of cases (as you have noticed when running in the IDE vs command line).
The Class.getResource(String) is only reliable if you lookup a file (not a directory).
Consider that the Jetty Project Embedded Cookbook recipes have techniques for this.
See:
WebAppContextFromClasspath.java
ResourceHandlerFromClasspath.java
DefaultServletFileServer.java
DefaultServletMultipleBases.java
XmlEnhancedServer.java
MultipartMimeUploadExample.java
Example:
// Figure out what path to serve content from
ClassLoader cl = ManualJetty.class.getClassLoader();
// We look for a file, as ClassLoader.getResource() is not
// designed to look for directories (we resolve the directory later)
URL f = cl.getResource("webapp/index.html");
if (f == null)
{
throw new RuntimeException("Unable to find resource directory");
}
// Resolve file to directory
URI webRootUri = f.toURI().resolve("./").normalize();
System.err.println("WebRoot is " + webRootUri);
WebAppContext context = new WebAppContext();
context.setBaseResource(Resource.newResource(webRootUri));
I have a an ear file to be deployed on weblogic 12c.
I have following project structure :
1) prop-application which is an .ear file
2) prop-service which is a .jar file
3) prop-framework which is a .jar file
All are maven project.
- prop-service contains prop-framework as one of its maven dependency.
- prop-application which is an ear contains prop-service
so we can say : prop-application.ear = prop-service.jar + prop-framework.jar
prop-service.jar = more java codes + prop-framework.jar
Now there is a class in prop-framework as :
#Stateless(name = "ServiceCallerBean")
public class ServiceCallerBean implements ServiceCaller
#Local
public interface ServiceCaller
Requirement :
Now i want to lookup(call) this EJB from a from a class in *prop-service* i.e a local look. The point here is to note that prop-service.jar contains prop-framework.jar
Following is the jndi names generated by weblogic 12c server :
java:global/ProposalEngine/prop-service-0.0.1-SNAPSHOT/ServiceCallerBean.>
java:module/ServiceCallerBean.>
java:app/prop-service-0.0.1-SNAPSHOT/ServiceCallerBean.>
java:global/ProposalEngine/prop-service-0.0.1-SNAPSHOT/ServiceCallerBean!com.db.serviceframework.ejb.ServiceCaller.>
java:app/prop-service-0.0.1-SNAPSHOT/ServiceCallerBean!com.db.serviceframework.ejb.ServiceCaller.>
java:module/ServiceCallerBean!com.db.serviceframework.ejb.ServiceCaller.>
I can't use those jndi names which contains jar version(eg 0.0.1-SNAPSHOT) because jar version will keep on changing. But if i use any of the jndi names like java:module/ServiceCallerBean , then there lookup fails with javax.naming.NameNotFoundException: While trying to lookup error
I have tried even :
#EJB
ServiceCaller serviceCaller
in the required class in prop-service but serviceCaller comes out to be null here. Searched on this issue and found that we can use #EJB in only container managed classes, not in simple java class.
I have tried everything but noting seems to be working. So plz help me to solve this issue.
This blog contains a nice explanation of where the JNDI addresses come from. The prop-service-0.0.1-SNAPSHOT entry is taken from the name of the JAR or WAR, so you can use the Maven JAR plugin to change the final name of your JAR you should be able to remove the version number, like this.
I have an OSGi Bundle and a servlet. Now I want to access the bundle from the servlet. For that purpose I use the following in the servlet:
#Resource
BundleContext context
...
ServiceReference ref = context.getServiceReference("package.MyOSGiServiceInterface");
MyOSGiServiceInterface service = context.getService(ref);
The Problem is that my servlet doesn't know MyOSGiServiceInterface 'cause that is defined in the OSGiBundle. In Eclipse I added a reference to the bundle Project in my Build Path. But at runtime it obviously can't find it.
To solve that Problem I played around with
(in bundle manifest)
Export-Package: package-of-osgi-service-interface
(in servlet manifest)
Import-Package: package-of-osgi-service-Interface
Dependencies: ...,deployment.MyBundle
But I couldn't solve it.
Whats the missing step? How can I tell JBoss to add the package containing MyOSGiServiceInterface in OSGiBundle to the class path?
Thanks for answers!
(JBoss AS 7.1.1)
--> error message <--
Eventually I solved it. I had to put the right combination of settings together to reach my goal:
Deploy the bundle per: File - Export - "Deployable plug-ins and fragments" into folder: "jboss/standalone/deployments"
Bundle-Manifest:
Bundle-SymbolicName: TestBundle
Bundle-Version: 1.0.0
Export-Package: "package-which-includes-my-service"
Servlet-Manifest:
Dependencies: org.osgi.core,org.jboss.osgi.framework,deployment.TestBundle:1.0.0
Import-Package: "package-which-includes-my-service"
I am trying to access static resource (eg. first.html) packed inside the same .jar file (testJetty.jar), which also has a class which starts the jetty (v.8) server (MainTest.java). I am unable to set the resource base correctly.
The structure of my jar file (testJetty.jar):
testJetty.jar
first.html
MainTest.java
==
Works fine on local machine, but when I wrap it in jar file and then run it, it doesn't work, giving "404: File not found" error.
I tried to set the resourcebase with the following values, all of which failed:
a) Tried setting it to .
resource_handler.setResourceBase("."); // Results in directory containing the jar file, D:\Work\eclipseworkspace\testJettyResult
b) Tried getting it from getResource
ClassLoader loader = this.getClass().getClassLoader();
File indexLoc = new File(loader.getResource("first.html").getFile());
String htmlLoc = indexLoc.getAbsolutePath();
resource_handler.setResourceBase(htmloc); // Results in D:\Work\eclipseworkspace\testJettyResult\file:\D:\Work\eclipseworkspace\testJettyResult\testJetty1.jar!\first.html
c) Tried getting the webdir
String webDir = this.getClass().getProtectionDomain()
.getCodeSource().getLocation().toExternalForm();
resource_handler.setResourceBase(webdir); // Results in D:/Work/eclipseworkspace/testJettyResult/testJetty1.jar
None of these 3 approaches worked.
Any help or alternative would be appreciated
Thanks
abbas
The solutions provided in this thread work but I think some clarity to the solution could be useful.
If you are building a fat jar and use the ProtectionDomain way you may hit some issues because you are loading the whole jar!
class.getProtectionDomain().getCodeSource().getLocation().toExternalForm();
So the better solution is the other provided solution
contextHandler.setResourceBase(
YourClass.class
.getClassLoader()
.getResource("WEB-INF")
.toExternalForm());
The problem here is if you are building a fat jar you are not really dumping your webapp resources into WEB-INF but are probably going into the root of the jar, so a simple workaround is to create a folder XXX and use the second approach as follows:
contextHandler.setResourceBase(
YourClass.class
.getClassLoader()
.getResource("XXX")
.toExternalForm());
Or change your build tool to export the webapp files into that given directory. Maybe Maven does this on a Jar for you but gradle does not.
Not unusually, I found a solution to my problem. The 3rd approach mentioned by Stephen in Embedded Jetty : how to use a .war that is included in the .jar from which Jetty starts? worked!
So, I changed from Resource_handler to WebAppContext, where WebAppContext is pointing to the same jar (testJetty.jar) and it worked!
String webDir = MainTest.class.getProtectionDomain()
.getCodeSource().getLocation().toExternalForm(); ; // Results in D:/Work/eclipseworkspace/testJettyResult/testJetty.jar
WebAppContext webappContext = new WebAppContext(webDir, "/");
It looks like ClassLoader.getResource does not understand an empty string or . or / as an argument. In my jar file I had to move all stuf to WEB-INF(any other wrapping dir will do). So the code looks like
contextHandler.setResourceBase(EmbeddedJetty.class.getClassLoader().getResource("WEB-INF").toExternalForm());
so the context looks like this then:
ContextHandler:744 - Started o.e.j.w.WebAppContext#48b3806{/,jar:file:/Users/xxx/projects/dropbox/ui/target/ui-1.0-SNAPSHOT.jar!/WEB-INF,AVAILABLE}
I am trying to add jbox2d as a dependency to my project in netbeans (playn-jbox2d-1.1-SNAPSHOT.jar), but at run time, I get:
Exception in thread "main" java.lang.NoClassDefFoundError: org/jbox2d/collision/shapes/Shape
All other classes can be accessed fine, just not Shape.
I simply right clicked dependencies in my core directory and did add dependency and searched for jbox2d.
Anyone know what could be wrong?
What version of jbox2d do you have, as a dependency? You can crosscheck in the dependency jar file, if that class (Shape.class) exists or not?
EDIT: Most of the times, 'NoClassDefFoundError' happens due to incorrect classpath settings or when there's more than one class (or jar file) in the classpath, with the same namespace.