Is it possible to include module-info.class from asm5 scanning in Apache TomEE via a system.property? Jackson 2.13.2 jars have Java 11 module-info class which fails the asm scan because it's compiled above Java 8. I tried "openejb.additional.exclude = jackson-" which then allows the war to start but fails at runtime because it can't find classes. If I could exclude module-info.class, I should be able to start the application and have required classes loaded at runtime
Related
I have a JDK 9 project. When running mvn install, everything works fine. When using IntelliJ 2017.2.6 with JDK 9.0.4 I come up
with dozens of compilation errors due to split packages. For example, in my POM I set a dependency on org.apache.solr:solr-core:7.2.1. One of the errors displayed by IntelliJ is:
Error:java: module solr.core reads package org.apache.lucene.search from both lucene.misc and lucene.sandbox
The rationale for the compilation error issued by IntelliJ is:
solr-core has Maven dependencies on artifacts lucene-misc and lucene-sandbox
Both lucene-misc.jar and lucene-sandbox.jar define classes in package org.apache.lucene.search
IntelliJ considers that lucene-misc.jar and lucene-sandbox.jar are JDK 9 modules (if fact, they are not modules, they have no module-info.java file). As two JDK 9 modules cannot participate to the same package, IntelliJ issues a compilation error.
By contrast, the Maven compiler pluging issues no error, because it considers lucene-misc.jar and lucene-sandbox.jar as belonging to
the class path, not to the module path.
I obviously don't want to re-package the Lucene stuff.
So my problem boils down to the following: how can I mute IntelliJ errors Error:java: module Mod1 reads package P from both Mod2 and Mod3?
[Short]
It's impossible if you want to run your application from a module code. You have to migrate your code which depend on collision JARs to non-module code and add your collitions jar on the class path. (as suggested in comments)
[Long]
Behind the scene the Intellij try to run the JVM, so the Intellij can run your application only if the JVM can do that.
When you run an application from module jar, that means that you run your application from named module. The module must require all of its dependencies which should be name modules. Note that even automatic modules which are created from your non-module JARs are indeed named.
Java 9 does not allow split-packages for the reason of the reliable configuration, only unnamed modules are excepted from this rule.
The only way to make it works it move your collision jars to unnamed module, but named module cannot depend on unnamed module
A named module cannot, in fact, even declare a dependence upon the unnamed module. This restriction is intentional, since allowing named modules to depend upon the arbitrary content of the class path would make reliable configuration impossible.
so if you don't want repackage collision jars you have to move your modules which require collision jars to non-module jar.
Your maven plugin done with it, because as #Nicolai said:
Maven places them on the class path (where split packages don't matter), whereas IntelliJ places them on the module path (leading to the problems you observe).
See also this answer about running the application from non-module code.
In order to be able to use my Eclipse plugin "treezCore" also as a Java9 module I created a module-info.java in my src folder.
Furthermore, I moved the Plug-in Dependencies from the Classpath to the Modulepath. I can see a module "org.eclipse.swt.3.106.1.v20170926" in the plugin dependencies:
However, I am not able to reference that module in my module-info.java. I tried
require org.eclipse.swt.3.106.1.v20170926;
require org.eclipse.swt;
require swt;
None of those options worked. The jar file \plugins\org.eclipse.swt_3.106.1.v20170926-0519.jar that is used by Eclipse does not contain a module definition and
jar --file org.eclipse.swt_3.106.1.v20170926-0519.jar -d
says that the module descriptor can not be derived. Also see
Unable to derive module descriptor for auto generated module names in Java 9?
If I download a newer version of swt.jar from
http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.1a-201710090410/download.php?dropFile=swt-4.7.1a-win32-win32-x86_64.zip
I get following output that looks promising:
swt automatic
requires java.base mandated
contains org.eclipse.swt
contains org.eclipse.swt.accessibility
contains org.eclipse.swt.awt
contains org.eclipse.swt.browser
contains org.eclipse.swt.custom
contains org.eclipse.swt.dnd
contains org.eclipse.swt.events
contains org.eclipse.swt.graphics
contains org.eclipse.swt.internal
contains org.eclipse.swt.internal.gdip
contains org.eclipse.swt.internal.image
contains org.eclipse.swt.internal.mozilla
contains org.eclipse.swt.internal.mozilla.init
contains org.eclipse.swt.internal.ole.win32
contains org.eclipse.swt.internal.opengl.win32
contains org.eclipse.swt.internal.webkit
contains org.eclipse.swt.internal.win32
contains org.eclipse.swt.layout
contains org.eclipse.swt.ole.win32
contains org.eclipse.swt.opengl
contains org.eclipse.swt.printing
contains org.eclipse.swt.program
contains org.eclipse.swt.widgets
I also depend on org.eclipse.jface and could not find a seperate download for it.
=> Do I really have to wait for a new release of Eclipse that uses new plugin versions including module definitions?
Or can I somehow reference the old version of swt from the plugins folder, even if it does not include a module definition? I looked for an easy way to define an alias or a fallback dependency e.g.
requires ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar as 'org.eclipse.swt'
or
requires org.eclipse.swt fallback ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar
but module-info.java does not seem to support such a syntax.
I have about 20 plugin dependencies and do not want to manually download each of them (if it would be possible) and include them as external jar file. Nor do I want to hack the individual Manifest/jar files in the Eclipse plugin folder. There are many jar files I would need to alter and an update of Eclipse would break that hack.
I am using Eclipse for RCP and RAP Developers, Version: Oxygen.1a Release (4.7.1a), Build id: 20171005-1200
Edit
When using Version: Photon Milestone 4 (4.8.0M4) Build id: 20171214-1849, the error in module-info.java vanishes when using
require org.eclipse.swt;
and having the Plug-in Dependencies in the Modulepath.
However, my imports do not work yet, see following image. If I move the Plug-in Dependencies from the Modulepath to the Classpath, the imports work but the error in module-info.java reappears.
I created a min example at
https://github.com/stefaneidelloth/Java9EclipsePluginExample/tree/master/MyPlugin
and I filed a bug report at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529089
Related questions:
How to use 3rd party library in Java9 module?
Unable to derive module descriptor for auto generated module names in Java 9?
Force Eclipse (Helios) to use a newer version of SWT at application runtime
JFace libraries stand-alone download (not picked from Eclipse plug-ins)
New Keywords in Java 9
What you observe is tracked in bug 525660, which starts with the observation that all existing (OSGi) artifacts of Eclipse don't work as automatic modules, because Java 9 fails to derive a valid module name from jar filenames of the shape org.eclipse.swt_3.106.1.v20170926-0519.jar.
Since this was discovered too late to request improving the algorithm for automatic module name derivation, this can only be fixed by adding Automatic-Module-Name headers to the manifests of future releases.
This header is present starting from Photon M4 as can be seen in org.eclipse.swt_3.107.0.v20171205-0742.jar, containing:
Automatic-Module-Name: org.eclipse.swt
I am trying to deploy a war onto a IBM Websphere Application Server Community Edition (WASCE) 3.0.0.3. I had some jars conflicting problems between those jars that comes with WASCE 3.0.0.3 and the jars comes from our application dependencies. At the end, I fixed the problem by using below property in geronimo-web.xml to force WASCE to load jars from my application.
<import-package>!the.conflicting.jars</import-package>
However, I would like to force WASCE to always take jars from my application first, i.e. inverse the default classloader behavior to load from application first. What is the correct config to change in this case?
After some searches, WASCE 3.0 is based on Geronimo 3.0 according to link. I found setting <inverse-classloading> in geronimo-web.xml may be helpful. But below two documents on Apache Geronimo 3.0 website mention that this function is no longer available on Geronimo 3.0
in Migrating from G 2.x to G 3.x, it says:
inverse-classloading Geronimo 3.0 does not support the element in the deployment plan.
in geronimo-web.xml,
The <sys:environment> element contains the following elements:
...
The <inverse-classloading> element can be used to specify that standard classloader delegation is to be reversed for this module. The Geronimo classloader delegation follows the Java EE 5 specifications, and the normal behavior is to load classes from a parent classloader (if available) before checking the current classloader. ...... ...... (Not supported in 3.0, use <import-package/> instead)
So if <inverse-classloading> is no longer available, what is the equivalent of this property in WASCE 3.0.0.3? Or how exactly should I do this using <import-package/> for all duplicated jars?
In the link you mentioned you will find the following section
<sys:environment>
The <sys:environment> XML element uses the Geronimo System namespace, which is used to specify the common elements for common libraries and module-scoped services, and is documented here:
http://geronimo.apache.org/schemas-3.0/docs/geronimo-module-1.2.xsd.html
The element contains the following elements:
The <moduleId> element is used to provide the configuration name for the web application as deployed in the Geronimo server. It contains elements for the groupId, artifactId, version and module type. Module IDs are normally printed with slashes between the four components, such as GroupID/ArtifactID/Version/Type.
The <dependencies> element is used to provide the configurations and third party libraries on which the web module is dependent upon. These configurations and libraries are made available to the web module via the Geronimo classloader hierarchy.
The <bundle-activator> element is used to create Bundle-Activator header in the manifest file of the web application. It specifies the entry point of the web application as deployed in the Geronimo server.
The <bundle-classPath> element is used to create Import-Package header in the manifest file of the web application. It contains a list of directories or embedded jar files, which are also called bundle resources and extend the classpath of the web application.
The <import-package> element is used to create Import-Package header in the manifest file of the web application. It specifies a list of packages to be resolved before the web application is started. Use <import-package>!packagename</import-package> to override the specific package in server.
The <export-package> element is used to create Export-Package header in the manifest file of the web application. It specifies a list of packages to be exported.
The <require-bundle> element is used create Require-Bundle header in the manifest file of the web application. It specifies a list of bundles to bind to regardless their packages.
The <dynamic-import-package> element is used to create DynamicImport-Package header in the manifest file of the web application. It specifies a list of packaged to be imported dynamically, especially during class loading.
So basically, you need to add the following directive i.e
<sys:import-package>!package-class-name-here*</sys:import-package> within the <sys:environment> stanza. Typically before the Application Context-Root directive.
As you already know, this is in the geronimo-web.xml embedded in the Application WAR/EAR -- as mentioned in the link
http://geronimo.apache.org/GMOxDOC30/geronimo-webxml.html
I have 2 modules: ejb and war, and ear module, that contains them. Modules build successfully, but when I try to deploy ear to glassfish, I recieve this error:
glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=17;_ThreadName=Thread-2;|Exception while deploying the app [EarModule] : Invalid ejb jar [BackEnd-1.0-SNAPSHOT.jar]: 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.|#]
I really don't know what to do, I've found a lot of questions like mine, but there was no solution.
I understood, what was wrong. The problem was in run configurations, I'm using Intellij Idea and in run configurations there was build and make before run of my ear module. I removed this and after maven install it deployed successfully.
You have to add an EJB into your WAR or EAR file. Just Create a new Class and annotate it with #Stateless
I know this is very build specific and it uses Netbeans instead of the OP's IDE but because I was lead here and this will likely be useful to some users:
I had the following build:
Netbeans Enterprise Application with Maven
Glassfish 4.1
Java EE 7
I had tried migrating from a previous non-maven enterprise application and the clone didn't quite work the way I expected, there was some old ejb jars lying around that I deleted.
I had done quite a few things to fix it:
Ensure theres no ejb jars lying around that shouldn't be there. Ensure that you don't have accidently have the ejb module jar included more than once as this can result in the same error too (Manually deploying the ear and deployment through netbeans sometimes gave me different errors).
I used the #Remote interface on my EJB applications. Now you should not be importing your EJB into your War, you should use the annotations correctly as described https://docs.oracle.com/javaee/7/tutorial/ejb-intro004.htm
(This is more of a note) When you update any of your war or ejb, clean and build them before cleaning and building your ear (sounds funny right?).
If you are using interfaces for your session beans then you should put them in a separate jar, make a new project maven > java application. Do the same thing with your persistence entities. Add these as dependencies to both your ejb and war project.
This doesn't relate to me in particular but you should have at least 1 #stateless (or I think #stateful) annotation in a java class inside your ejb module for it to run (for the module to be considered an ejb).
I likely had to do a few more things that I forgot but if you still run into issues comment below and I'll try to update.
Just try to build & install your project using Maven , and then , deploy it in glassfish ( do not run your project directly from your IDE )
I encountered this problem as well. It occurred when I had imported a new EJB project into my Eclipse workspace. The project didn't have a reference to the Glassfish libraries then, since it was not yet included in the EAR deployment assembly.
Upon saving the Bean file, the IDE automatically imported javax.inject.Singleton instead of javax.ejb.Singleton. This made the code compile without warnings, but throw the same error as in the original post.
I am using Axway server which runs on jre 1.5 . So it accepts all classed builded below 1.6 . But problem is I read THIS LINK and I got this line as guide
Environment:
* Java Developer Kit (JDK) 1.4.x or greater for deployment and 1.5.x (Java 5) for compiling/building. As of AMQ 5.5.0 you need JDK 1.6.0 to**
Which says I can use ActiveMQs below version 5.5 for jre 1.5.
when I use ActiveMQ 5.4.3 am getting bad class version error.Please help me.
This is the line where am getting this error
Object o = Class.forName("org.apache.activemq.ActiveMQConnectionFactory",
true,ConnFactory.class.getClassLoader())
.newInstance();
You could extract the jar as a zip file, and then look inside the folder and check inside the META-INF directory. The MANIFEST.MF file will tell you what version of the jvm the jar was compiled with. I just grabbed the 5.4.3 version of the activemq jar and it said this:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: chirino
**Build-Jdk: 1.6.0_26**
Specification-Title: ActiveMQ :: Jar Bundle
Specification-Version: 5.4.3
Specification-Vendor: The Apache Software Foundation
Implementation-Title: ActiveMQ :: Jar Bundle
Implementation-Version: 5.4.3
Implementation-Vendor-Id: org.apache.activemq
Implementation-Vendor: The Apache Software Foundation
which clearly shows that it was built with the 1.6 jvm. Might need to download the source and build it on 1.5 manually.
In maven repository the last version of activemq built on jdk 1.5 is 5.4.2.
Problem is due to the jvm config file entry for jar newly added.
I don't know and I am not responsible and I don't have permission to do any Admin related privileges.
I put the jar in CLASSPATH exactly.So its ok for all the classes to access that.
But problem is in JVM config file I have to put the entry, I mean I have to give name of the jar with CLASSPATH in jvm.config file of axway.Though I put my jar in class path without put entry in jvm.config, it is worthless.Because while jvm get initialized it checks the config file first to add jar with it.