When JodaTime v. 2.5 library included into WAR file deployment fails in GF 5.0 with following error. It seems problem lies in hibernate-validator. FutureValidatorForReadableInstant is not loaded as ReadableInstant is not loaded by hibernate-validator bundle in GF5.0 while it is working GF 4.1.2.
Exception while loading the app : CDI deployment failure:Errornstantiating :org.hibernate.validator.cdi.internal.ValidationExtension
Caused by: java.lang.TypeNotPresentException: Type org.joda.time.ReadableInstant not present
at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:117)
at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)
at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
at sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:68)
at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:138)
at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
at sun.reflect.generics.repository.ClassRepository.getSuperclass(ClassRepository.java:90)
at java.lang.Class.getGenericSuperclass(Class.java:777)
at org.hibernate.validator.internal.util.TypeHelper.resolveTypeForClassAndHierarchy(TypeHelper.java:386)
at org.hibernate.validator.internal.util.TypeHelper.resolveTypes(TypeHelper.java:351)
at org.hibernate.validator.internal.util.TypeHelper.extractType(TypeHelper.java:327)
at org.hibernate.validator.internal.engine.constraintvalidation.ClassBasedValidatorDescriptor.(ClassBasedValidatorDescriptor.java:39)
at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintValidatorDescriptor.forClass(ConstraintValidatorDescriptor.java:49)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at org.hibernate.validator.internal.metadata.core.ConstraintHelper.putConstraints(ConstraintHelper.java:686)
at org.hibernate.validator.internal.metadata.core.ConstraintHelper.(ConstraintHelper.java:386)
at org.hibernate.validator.internal.engine.ValidatorFactoryImpl.(ValidatorFactoryImpl.java:155)
at org.hibernate.validator.HibernateValidator.buildValidatorFactory(HibernateValidator.java:38)
at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:322)
at org.hibernate.validator.cdi.internal.ValidationExtension.(ValidationExtension.java:116)
... 78 more
I think it might be a bug in Hibernate Validator. I created https://hibernate.atlassian.net/browse/HV-1490 to track this issue.
When we try to detect Joda Time in ConstraintHelper, we use the LoadClass mechanism which might fall back to using the Thread Context class loader if it does not find the class within the ConstraintHelper/HV CL.
In your case, I think the ReadableInstant class is accessible in the TCCL but not in the HV CL.
When we try to get the type from the ConstraintValidator, we only have the HV CL and so it fails to find the class.
So I think we should fix that in HV but I'm not sure it will help you as, once fixed, the Joda Time constraint validators won't be enabled anyway.
What might not help is that the OSGi bundle of HV looks a bit outdated regarding the Joda Time dependency (https://github.com/javaee/glassfish/blob/master/nucleus/packager/external/bean-validator/pom.xml#L124). I'll see with the GlassFish team if they can update it.
I created a PR https://github.com/hibernate/hibernate-validator/pull/857 to fix the issue on our side. You might be able to get this branch, build it (it's just a mvn clean install) and upgrade the jars in your GlassFish. As mentioned above, it won't allow you to use constraints on Joda Time types but, at least, you should be able to start your app. I'm interested in your feedback if you can try that.
About the GF part, I emailed the GF team and will let you know if there is some progress on that front.
Update: GF 5.0.1 will contain a fix for this issue. If you upgrade your current GF to HV 6.0.3.Final we released today, you should be able to start your app (but won't be able to put constraints on Joda Time types, this would have to wait for GF 5.0.1).
Related
I'm a contributor of Vert.x for Groovy (https://github.com/vert-x3/vertx-lang-groovy) and recently see a curious behaviour regarding AST Transformation.
Until Groovy 3.0.4 the VertxTransformation class (https://github.com/vert-x3/vertx-lang-groovy/blob/3.9/vertx-lang-groovy-gen/src/main/java/io/vertx/lang/groovy/VertxTransformation.java) was working just fine. When I tried to use Groovy 3.0.5 it started to appear some ConcurrentModificationException.
java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1044)
at io.vertx.lang.groovy.VertxTransformation.visit(VertxTransformation.java:82)
at io.vertx.lang.groovy.VertxTransformation.visit(VertxTransformation.java:77)
at io.vertx.lang.groovy.VertxTransformation.lambda$visit$0(VertxTransformation.java:68)
at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
at io.vertx.lang.groovy.VertxTransformation.visit(VertxTransformation.java:68)
Below there are two links: the first one shows the project building fine with 3.0.4 and the second one failing with 3.0.5. The only thing different is the Groovy version.
https://travis-ci.org/github/vert-x3/vertx-lang-groovy/builds/712642226 (3.0.4)
https://travis-ci.org/github/aaloise/vertx-lang-groovy/builds/712638741 (3.0.5, the exception appears from line 1818 onwards)
Don't know if something changed in 3.0.5 regarding AST. I even raised an issue (https://issues.apache.org/jira/projects/GROOVY/issues/GROOVY-9666). If is not a bug, but an improvement, would like some suggestions for an workaround.
I believe this problem not to be related to module exclusions in JDK 9 (as with java.se.ee), but rather with the fact that JDK 9 includes a newer version of org.w3c.dom.ls in the java.xml module that does not have the DocumentLS class.
The important bit of the stack trace is this:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [spring-test/test-container.xml]; nested exception is java.lang.NoClassDefFoundError: org/w3c/dom/ls/DocumentLS
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181)
Even if I include a runtime dependency with this class, like xerces:xerces 2.4.0, the JDK java.xml module is preferred (I guess).
I am using Gradle 4.1. Is there any way to restrict the scope of a
JDK provided module?
As you have correctly analyzed, the package org.w3c.dom.ls is present in the platform module java.xml. Any class on the class path that is in the same package will be ignored. That's called a split package and several fixes exist - the following two might help you.
Patch java.xml
You can add the classes of the Xerxes JAR to the java.xml module with --patch-module:
java --patch-module java.xml=xerxes-4.0.0.jar ...
I've never tried that with a JAR that contains some of the same classes. As I understand it, the JDK classes will then be replaced with the Xerxes classes, which means they better be a fully binary compatible replacement.
Upgrade java.xml
Another hope is to replace java.xml with the upgrade module path:
The upgrade module path (--upgrade-module-path) contains compiled definitions of modules intended to be used in place of upgradeable modules built-in to the environment (compile time and run time).
You face two problems:
the upgrade module path is supposed to be used only for upgradable modules (which java.xml is not), but I think I've read somewhere that that's not enforced (yet?) - didn't try it
the artifact you replace java.xml with needs to be fully binary compatible update - would that be the case for Xerxes?
From what I can tell, DocumentLS is from a 2002 draft of the W3C API, it doesn't appear to have made it into a released version. It looks like xerces-2.4.0 (from 2006?) includes it but newer versions don't. So upgrading to a more recent Xerces may be needed here. If Spring really depends on DocumentLS then it will need to be updated too.
I am trying to generate Excel using Xssf API because its memory footprint is small.
It is working fine in my local machine which is having jdk1.7.
But when I try to run it on UNIX where java version is 1.6.0_75 it gives me the following error.
java.lang.NoClassDefFoundError: Could not initialize class org.apache.poi.openxml4j.opc.internal.marshallers.ZipPackagePropertiesMarshaller
I have following jars in my classpath
poi-3.11-20141221.jar
poi-excelant-3.11-20141221.jar
poi-ooxml-3.11-20141221.jar
poi-ooxml-schemas-3.11-20141221.jar
xmlbeans-2.6.0.jar
xercesImpl.jar
I have verified that poi-3.11-20141221.jar has the ZipPackagePropertiesMarshaller class.
Seems that some jar is missing.
Am I missing something?
I have found a solution to my own problem.
I replaced poi-3.11-20141221.jar with poi-ooxml-3.9.jar. That worked.
Java version 1.6.0_75 does not exists, I suppose you make a typo. The last update of Java 6 is the update 45 (6u45).
The class ZipPackagePropertiesMarshaller is loaded at run-time for sure. The exception NoClassDefFoundError occurs during the initialization phase; if the exception had been ClassNotFoundException, it would have been different...
The class ZipPackagePropertiesMarshaller is unaltered between the versions 3.11 and 3.9, but the class PackagePropertiesMarshaller extended by ZipPackagePropertiesMarshaller is changed: the main change regards the use of StAX in the newer version.
The distribution of StAX coming with Java 6, but the version of Java 6 update 18 (http://www.oracle.com/technetwork/java/javase/6u18-142093.html) introduces the StAX 1.2 API version.
Consider to use Java 6u18 or newer. This should solve your problem.
In the official FAQ there are some indications about a similar problem: https://poi.apache.org/faq.html#faq-N1017E.
Moreover, the workaround you found is not the best one, see the last FAQ of POI.
Running CentOS 6.5 and RedHawk 1.9.0, and I have audio-components installed in $SDRROOT, and AudioSink shows up in palette, all good. However when I double click to launch it I get the error:
Launching component AudioSink_1 has encountered a problem
and
Failed to launch: AudioSink_1.
When I click on details I get:
Failed to launch: AudioSink_1
and
IDL:CF/ExecutableDevice/ExecuteFail:1.0
Not very informative. Components AudioSource and AudioTestSource also do not launch.
I was having a very similar issue to what you described when I was trying to use Axios-Engineering's RTLTcpSource component. What the issue was for me was I was installing the component incorrectly. So for me this is how I installed a component in REDHAWK.
Download the original source code. (unzip if necessary)
Open the REDHAWK IDE(eclipse)
File->Import...->Existing Projects into Workspace->next->select the source code folder->Finish
Project->Build Project
Drag project folder to "Target SDR" in the SCA Explorer
I hope this helps you or anyone else. I know there aren't really many places that tell you how to actually add an external component to REDHAWK and it took me a while to figure out to just treat it like a normal custom component.
I had a similar problem when using audiosink. The answer above by JD will work but make sure you re-gen the component since the code was made in 1.84 and there is a new codegen for 1.9.
It may also throw a message saying there are errors when exporting to the target SDR but that can mostly be ignored from my experience.
Similarly if you want more of an output, you can run the component/device through the terminal sandbox after building it and set "-Debug 4" to get more information.
Good luck!
edit: seems like a bug with audiosink was addressed: AudioSink unknown error
you might want to just pull down the updated version and try that!
Per JAXB specification http://jaxb.java.net/2.2.4/docs/xjc.html if you want to run the JAXB-XJC compiler, one of the of the extensions/arguments you may pass is -Xpropertyaccessors even though it has been specfied in each of JAXB-RI till the latest one 2.2.5u2 still when I try to run it passing this argument I get 'unrecognized parameter -Xpropertyaccessors' is not specified in the help menu when I run it. It is important for me to have the access levels on properties not fields.
I have followed up with the JAXB RI lead, apparently the plugin is there but not enabled. The issue will be fixed in versions 2.1.14 and 2.2.6 of the JAXB RI. I would recommend entering a bug so that you will be able to track the status of the issue.
http://java.net/jira/browse/JAXB/