When I try to build my Enterprise Project in Netbeans with ant, i got this exception:
warning: Supported source version 'RELEASE_6' from annotation
processor
'org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor'
less than -source '1.8'
Note: Creating static metadata factory ...
An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file
javax/persistence/PersistenceException
I only have some entityclasses in my ejb module.
This error is reported as a bug in NetBeans (with a resolved status as it turns out to be considered as a "user error"). Below is the main comment that explains the problem and gives the solution:
"ClassFormatError: Absent Code attribute in method..." is always indication that javaee-api-6.0.jar is used for runtime execution. The jar contains only method signatures (method bodies are stripped) and is suitable only for compilation. In future versions of javac there might be better error message.
The problem here is that javaee-api-6.0.jar is on classpath before EclipseLink jars and when EclipseLink annotation processor is started classes from javaee-api-6.0.jar are used instead of classes from EclipseLink. First thing is that javaee-api-6.0.jar should be removed from classpath of EJB project - it should not be needed as EJB project has an Application server selected and the project takes EE 6 APIs from that server.
As I understand the comment, you should try removing any reference to javaee-api-6.0.jar (which contains only "dummy" classes) from the classpath of the project, because the EclipseLink library should provide the correct classes used by the annotation processor.
Also, this question seems to tackle the same issue.
when you use the insert code and automatic bean creation it adds the Java EE 6
API library . I deleted the library and add the Java EE 7 API.
Related
I am compiling my legacy source code using JDK 9.0.1 as follows:
javac --add-modules=java.base,java.xml.ws -cp lib\jsr305.jar;lib\javax.annotation-api-1.2.jar TestJava.java
It gives an error because the annotations defined in jsr305.jar are not visible due to split module issue. The error is as follows:
TestJava.java:3: error: cannot find symbol
import javax.annotation.Nonnull;
^
symbol: class Nonnull
location: package javax.annotation
Here the module java.xml.ws.annotation is getting loaded since it is required for java.xml.ws. So it is ignoring the types in jsr305.jar. I don't want this module to be loaded but refer all its annotation types from javax.annotation-api-1.2.jar. I don't want to do --patch-module either because it would break in future releases.
If I use --limit-module=java.xml.ws.annotation it gives the same error. If I remove java.xml.ws from -add-modules, it compiles successfully but I need to export few APIs from it so can't remove it. Is there any way I can load module java.xml.ws but not java.xml.ws.annotation?
EDIT : I think I have added some confusion by giving an example of split between java.xml.ws.annotaion and jsr305.jar. Though it's my actual problem, I am more interested in knowing - can I avoid loading a transitively dependent module, say loading java.xml.ws without loading java.xml.ws.annotation? As per my understanding in JEP 261 it says,
--limit-modules <module>(,<module>)*
where <module> is a module name. The effect of this option is to limit
the observable modules to those in the transitive closure of the named
modules plus the main module, if any, plus any further modules
specified via the --add-modules option.
So, why isn't --limit-module preventing java.xml.ws.annotation from loading?
I know of no way to prevent resolution of a transitive dependency.
Short-term fix
You should be able to make it work by patching the module with --patch-module java.xml.ws=lib\jsr305.jar:lib\javax.annotation-api-1.2.jar. My opinion: If you just want to get your build working on Java 9, that is a good choice. It's a little dubious but still acceptable if you want to use it in production.
If you're worried about long-term compatibility:
I don't think --patch-module will disappear any time soon - do you have a source for that?
I'm pretty sure java.xml.ws will be removed quite soon - it is already deprecated for removal.
In your place I'd worry about the module more than about patching it.
Long-term solution
So for a long-term solution you should remove your dependency on java.xml.ws. JDK-8189188 has a section on this (with lots of links that I was too lazy to copy):
The Reference Implementations (RIs) of JAX-WS and JAXB are a good starting point because they are complete replacements for the java.xml.ws and java.xml.bind modules in JDK 9. The RIs are available as Maven artifacts: (note that they must be deployed on the classpath)
com.sun.xml.ws : jaxws-ri (JAX-WS, plus SAAJ and Web Services Metadata)
com.sun.xml.bind : jaxb-ri (JAXB)
The tools for JAX-WS and JAXB are also available as Maven artifacts:
wsgen and wsimport: com.sun.xml.ws : jaxws-tools, plus tool scripts
schemagen and xjc: com.sun.xml.bind : jaxb-jxc and com.sun.xml.bind : jaxb-xjc, plus tool scripts
There are also Maven artifacts that contain just the APIs of the Java EE technologies:
javax.xml.ws : jaxws-api (JAX-WS, plus javax.xml.soap : javax.xml.soap-api for SAAJ and javax.xml : webservices-api for Web Services Metadata)
javax.xml.bind : jaxb-api (JAXB)
javax.activation : javax.activation-api (JAF)
javax.annotation : javax.annotation-api (Common Annotations)
Adding either the API JARs or the reference implementations to your class path together with all other javax.annotation-related JARs will work because all class path content ends up in the same module (the unnamed one) and thus split packages are no problem there.
Websphere 8.0.0.11
Hibernate 4.2.21.Final
I have found many questions about this same problem but none of them worked for me.
If I deploy the application in Websphere it works OK.
However we have defined a shared library that contains all the third party libraries (spring, hibernate, javassist, etc) so that our WARs are thinner.
This way during deployment we associate our thin WAR against that Websphere shared library.
The point is that when we deploy the application this way the ClassCastException Hibernate exception _$$_javassist_856 cannot be cast to javassist.util.proxy.Proxy is thrown.
I have checked the loaded jars in the websphere console and can only see one javassist jar (3.18.1-GA) in the classpath.
Why could this be happening?
UPDATE
I have also tried using PARENT_FIRST and PARENT_LAST class loading.
UPDATE 2
I just found out that Websphere is loading its own javassist jar:
URL location = ProxyFactory.class.getProtectionDomain().getCodeSource().getLocation();
logger.info("{}", location);
It prints: file:/opt/IBM/WebSphere/AppServer/plugins/javassist.jar
After trying pretty much everything I found on S.O. without any success I decided to downgrade Hibernate to version 4.1.12.Final. This is the maximum 4.x version compatible with Websphere 8.x.
The problem is that Javassist leaves traces in its generated code. With Javassist on the class path twice, its classes are loaded twice. Two types are however only equal if they have the same name and are loaded by the same class loader. In your case, the generated class resolves its Javassist dependeny to a type that is loaded by your application class loader while your code is casting the instance to the Javassist type that is loaded by the Websphere class loader (or the other way around).
Are you sharing any Hibernate dependencies between applications? Try to not use any shared libraries related to Hibernate in your application to avoid this.
I am trying to add metrics library to existing webservice on WAS 7. I am getting below error
Error 404: javax.servlet.UnavailableException: SRVE0203E: Servlet [AdminServlet]: com.yammer.metrics.reporting.AdminServlet was found, but is missing another required class. SRVE0206E: This error typically implies that the servlet was originally compiled with classes which cannot be located by the server. SRVE0187E: Check your class path to ensure that all classes required by the servlet are present.SRVE0210I: This problem can be debugged by recompiling the servlet using only the classes in the application's runtime class path SRVE0234I
What are the other run-time dependencies required for metrics-servlet-2.2.0?
I have metrics-core-2.2.0.jar and metrics-servlet-2.2.0.jar in my WEB-INF\lib folder.
Threads, ping and healthcheck servlets work fine.
I think your missing some more required jars, are you not using maven or gradle for dependency management
Please refer here to know all required jars that metrics-servlet-2.2.0.jar depends on. http://mvnrepository.com/artifact/com.yammer.metrics/metrics-servlets/3.0.0-BETA1
My suggestion is, it is always difficult to maintain dependencies without Maven/Gradle or any other build tools :).
I'm being driven out of my mind by the following exception:
java.lang.IllegalArgumentException:
com.sun.xml.messaging.saaj.soap.LocalStrings != com.sun.xml.internal.messaging.saaj.soap.LocalStrings
at java.util.logging.Logger.getLogger(Logger.java:357)
at com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl.<clinit>(SAAJMetaFactoryImpl.java:41)
It's occurring when I try to deploy a WAB (web application OSGi bundle) to Glassfish (3.1.1).
I'm trying to use an up-to-date version of SAAJ (com.sun.xml.messaging.saaj...) rather than the old JDK one (which is the com.sun.xml.internal.saaj... one), by putting the string com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl in the file META-INF/services/javax.xml.soap.MessageFactory.
It appears there is some logging going on before the OSGi classloading kicks in, and therefore the 'wrong' ResourceBundle is being returned during initialization of the static log field of com.sun.xml.messaging.saaj.soap.MessageFactoryImpl (SAAJ's implementation of javax.xml.soap.MessageFactory).
Anyone seen this / any workarounds on offer?
Never got to the bottom of this, but manifest voodoo eventually made it go away (with all of the javax.xml.ws / javax.ws.rs packages in Import-Package rather than on the bundle classpath WEB-INF/lib).
It was also possible to work around it by using
-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
on Glassfish startup, though obviously this forces that implementation on all users of MessageFactory.
See: JDK-6741342 : Logger.getLogger() throws java.lang.IllegalArgumentException on saaj classes.
Instead, it's related to the introduction of saaj into JDK 6.....and the workaround involved re-ordering jars.
I am playing with Weld-SE. I have a project which has pluggable modules. With one module, weld works. When other module, which uses weld-servlet-core, is put on classpath (with it's deps), CDI stops working, giving errors like "Unable to resolve dependency XY" or (after removing that #Inject) this:
Exception in thread "main" org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.jboss.weld.environment.se.jpa.JpaTransactionInterceptor</class> in jar:file:/mnt/ssd1/data/.m2/repository/org/jboss/jawabot/JawaBot-core/2.0.0-SNAPSHOT/JawaBot-core-2.0.0-SNAPSHOT.jar!/META-INF/beans.xml#11 is neither annotated #Interceptor nor registered through a portable extension
at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:466)
...
Although the class has #Interceptor (and the same class works fine with the other module).
When I debug WeldBootstrap#startContainer(Environment environment, Deployment deployment),
deployment.beanDeploymentArchive.beanClasses contains the interceptor
("org.jboss.weld.environment.se.jpa.JpaTransactionInterceptor").
I've checked the dependencies and TattleTale report, they all seem fine.
Any ideas what should I look at / try next?
The project is at http://ondrazizka.googlecode.com/svn/trunk/bots/JawaBot/branches/2.0/ To see the error, run mvn dependency:copy-dependencies java -cp ... org.jboss.jawabot.JawaBotApp Or simply run the web module in NetBeans.
Thanks, Ondra
Update: JIRA: https://issues.jboss.org/browse/WELD-940
Also, I found that it might be caused by a bug in Weld's scanning extension, <weld:scan>.
It was caused by using Weld's scanning extension, <weld:scan>:
An <includes> element contained package wildcard which resulted in matching classes in both "packages" (which is .jar in CDI / Weld's terminology IIUC).
I am not sure if I used it improperly or it's a bug.
See JIRA: https://issues.jboss.org/browse/WELD-940