In a Spring Boot project we use Eclipselink as ORM. We configured the build to weave statically and to package as jar. The interesting thing is that starting the program with mvn spring-boot:run works without problem, but starting with java -jar archive.jar works only if all entities are listed in the persistence.xml. Without having the class in the persistence.xml I get the error:
java.lang.IllegalArgumentException: No [ManagedType] was found for the key class [eltest.Customer] in the Metamodel - please verify that the [Managed] class was referenced in persistence.xml using a specific <class>eltest.Customer</class> property or a global <exclude-unlisted-classes>false</exclude-unlisted-classes> element
Also in the case, when we package the program as war, it starts without issues.
My questions are: Does the mvn spring-boot:runinvoke the static weaving at all, or does it weave at load-time? The same with the war deployment: does the war-build really invoke the static weaving, or is the weaving implicitly triggered, when the Tomcat starts the app? Is there a way to avoid listing the classes in the persistence.xml, and still go for statical weaving in a jar-packaging?
Here is an example:
https://github.com/gfinger/eltest
Build it with mvn clean package. If you start it with mvn spring-boot:run it uses Spring Data Rest to expose a Customer entity as REST resource. If you start it with java -jar target/static-eclipselink-0.0.1-SNAPSHOT.jar you get an error.
Related
I am running an open source piece of software (https://github.com/att/XACML) and the documentation says to use maven jetty to run the application. This works fine.
However, I am trying to run it without maven as a dependency, so I am thinking of using the generated war and deploying it with jetty. However, this approach gives me errors specific to the war (can not instantiate null etc.) that do not sure up when running maven jetty.
So my question is: how does maven jetty package the war? Is there anything it does at runtime that would make it different than just trying to deploy the war on its own? What is the difference between using maven jetty and using something like jetty runner with the war generated from maven clean install?
Jetty does not package a war.
Maven does, and you need ...
Your project's pom.xml should be declared as <packaging>war</packaging>
You have a src/main/webapp directory.
You have maven execute the package phase.
When you use something like mvn jetty:run-war the first thing that happens is the package phase executes, THEN the jetty:run-war goal executes.
See: JettyRunWarMojo.java
#Mojo(name = "run-war",
requiresDependencyResolution = ResolutionScope.COMPILE_PLUS_RUNTIME)
#Execute(phase = LifecyclePhase.PACKAGE)
public class JettyRunWarMojo extends AbstractMojo
Jetty is not doing the packaging of war, Maven and it's default package phase is (and the behaviors here are determined by the standard maven lifecycle defined by your <packaging>war</packaging>)
See: https://maven.apache.org/ref/3.2.2/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging
I am trying to understand the packaging of Spring Boot into "fat" jars. From what I know "fat" jars have their own special classes that load up the main class when the jar is running and also sets the classpath accordingly.
What I cannot understand is why when I use Eclipse to extract all my dependencies into a folder structure in the jar, the jar no longer runs as a correct Spring Boot application.
To repeat what I have done here just take a simple Spring Boot app and from Eclipse select the following-:
Export --> Runnable Jar --> Select Main Class --> Extract required libraries into jar.
Just run the jar from the command line as you would any jar. Spring Boot initially starts up but fails with the following message-:
2017-05-02 22:06:40.484 WARN 3468 --- [ main]
ationConfigEmbeddedWebA pplicationContext : Exception encountered
during context initialization - cancel ling refresh attempt:
org.springframework.beans.factory.BeanDefinitionStoreExcep tion:
Failed to process import candidates for configuration class
[com.main.Test Main]; nested exception is
java.lang.IllegalArgumentException: No auto configuration classes
found in META-INF/spring.factories. If you are using a custom packa
ging, make sure that file is correct.
Can I somehow edit the spring.factories file to include my classses ?
I just trying to understand how Spring actually packages the files through its Maven plugin.
I think that because it's a Spring Boot application, you need to use their plugin for building. It is because, spring Boot has its own jar loading mechanism for that (the BOOT-INF introduction in Spring Boot 1.4).
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
From documentation:
The Spring Boot Maven Plugin provides Spring Boot support in Maven, allowing you to package executable jar or war archives and run an application “in-place”.
Link to documetantion (Appendix E)
Something about spring.factories and locating auto-configuration candidates - Auto-configuration
I have update my project to use Spring BOOT 1.4.3. The code compiles and runs without issues from Eclipse Neon 1.
But when I run from command line
mvn clean install -DskipTests
java -jar myweb\target\my-web-1.0-SNAPSHOT.jar
I get runtime error and tomcat is not starting
Caused by: java.lang.NoSuchMethodError: org.apache.tomcat.util.res.StringManager.getManager(Ljava/lang/Class;)Lorg/apache/tomcat/util/res/StringManager;
at org.apache.catalina.util.LifecycleBase.<clinit>(LifecycleBase.java:43) ~[tomcat-embed-core-8.5.6.jar!/:8.5.6]
Please can you tell why? How to find which tomcat is used at runtime, as my understand is that 8.5.6 is having compile scope(?)
Please help. If the suggestion is to use tomcat.version in properties of POM file or add tomcat-juli dependency, then please help me understand why it is required?
Impatient stackoverflow'ers dont just flog new comers only because you can do. You can easily ask if you want my POM, but I used just spring-boot-starter-web thats it.
For this kind of problem, it's often due to multiple jar having the same class inside your classpath, so :
Find where this class / method could come from, by opening the type popup (CTRL + SHIFT + T in Eclipse). It will display you every jar in your classpath that contains the class.
Open the class in each jar to see which one contains your method and which one don't.
Display the dependency hierarchy of your project with mvn dependency:tree
If the 2 jars are in your classpath, you might exclude the one that don't contain the method.
I fail to understand why in the following minimal project my implementation of Spring's WebApplicationInitializer interface is found when running tests within Eclipse and IntelliJ, but not when using Maven (mvn clean test).
With Eclipse and IntellIJ I see INFO: Spring WebApplicationInitializers detected on classpath: [com.example.pack.DummyInitializer#26d678a4]
With mvn clean test I see INFO: No Spring WebApplicationInitializer types detected on classpath.
In the test I start an Embedded Tomcat:
String pathToWebXML = new File("src/main/webapp/").getAbsolutePath();
tomcat = new Tomcat();
tomcat.setBaseDir("embedded_tomcat");
tomcat.setPort(0);
tomcat.addWebapp("", pathToWebXML);
tomcat.start();
The web.xml references a ServletContextListener implementation which creates a new (and empty) AnnotationConfigWebApplicationContext.
I uploaded the example project to GitHub: https://github.com/C-Otto/webapplicationinitializer
As indicated in the comments, the classpath used by Maven Surefire (and Maven Failsafe) in the default setting is not scanned by Tomcat. Most classes are referenced using a MANIFEST.MF file inside a JAR file.
One option is to disable the useSystemClassLoader setting of the Maven plugins. However, this changes the details of the classloader, which may cause other problems.
As another option one could disable useManifestOnlyJar, which may cause problems on Windows machine.
In our project we decided to remove the initializer classes, and instead register whatever they were supposed to do manually. In a concrete example, as our implementation of AbstractSecurityWebApplicationInitializer was not found, we now register the security filter manually inside the contextInitialized method:
String filterName = AbstractSecurityWebApplicationInitializer.DEFAULT_FILTER_NAME);
servletContext.addFilter(filterName, new DelegatingFilterProxy(filterName)).addMappingForUrlPatterns(EnumSet.allOf(DispatcherType.class), false, "/*");
You can tell Tomcat to include the jars that are referenced via the manifest file in the jar created by surefire. This can be done in context.xml setting the Jar Scanner attribute scanManifest to true. This is the default in newer versions of Tomcat as stated here: https://bz.apache.org/bugzilla/show_bug.cgi?id=59961.
I've got a spring boot app and I'm building a myApp.jar using the spring-boot antlib. When I jar -tf myApp.jar I see that I have a jar called lib/foo.jar. Yet when I print out System.getProperty("java.class.path") I don't see that jar file on the classpath. I also get a ClassNotFound exception from URLClassLoader when the code attempts to use this class for the first time. I'm using the JarLauncher since that's what the antlib defaults to.
Any ideas why this jar file would not be on the classpath?
You won't see a bundled JAR in System.getProperty('java.class.path'). The class path specifies where the JVM will look in the filesystem for classes you attempt to load.
Spring Boot uses fat JARs, which are loaded in a completely different way. Refer to the Spring Boot documentation.