I had the following issue recently in my code. The environment is:
Java(TM) SE Runtime Environment (build pap6470sr1-20120330_01(SR1))
IBM J9 VM (build 2.6, JRE 1.7.0 AIX ppc64-64 20120322_106209 (JIT enabled, AOT enabled))
J9VM - R26_Java726_SR1_20120322_1720_B106209
Throwable occurred: java.lang.ArrayIndexOutOfBoundsException: Array index out of range: -14
at com.sun.xml.bind.v2.util.CollisionCheckStack.findDuplicate(CollisionCheckStack.java:133)
at com.sun.xml.bind.v2.util.CollisionCheckStack.push(CollisionCheckStack.java:71)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.writeTypeRef(XmlSchemaGenerator.java:705)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.access$1900(XmlSchemaGenerator.java:429)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace$ElementWithType.writeTo(XmlSchemaGenerator.java:1273)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.writeTo(XmlSchemaGenerator.java:583)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.access$600(XmlSchemaGenerator.java:429)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator.write(XmlSchemaGenerator.java:411)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.generateSchema(JAXBContextImpl.java:755)
at org.apache.cxf.jaxb.JAXBUtils.generateJaxbSchemas(JAXBUtils.java:760)
at org.apache.cxf.jaxb.JAXBDataBinding.generateJaxbSchemas(JAXBDataBinding.java:447)
at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:374)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:429)
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:637)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:492)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:240)
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:180)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:99)
at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:51)
at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:102)
at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:121)
at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:458)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:330)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:317)
at javax.xml.ws.Service.getPort(Service.java:130)
This code worked fine on Linux server with Oracle Java 1.7. It also worked on AIX with IBM Java 1.6. But it throws these exceptions when using IBM Java 1.7.
I did a research of com.sun.xml.bind.v2.util.CollisionCheckStack.findDuplicate(CollisionCheckStack.java:133)
And found some looking similar issues/answers, such as:
http://mydevtoolbox.blogspot.com/2013/07/jaxb-marshaller-no-threadsafe-error.html, which recommends “Create a Marshaller and Unmarshaller per request”
I don’t explicitly use Marshaller/Unmarshaller – it looks like CXF/JAXB issue on Java 1.7.
Any thoughts, insights, opinions are greatly appreciated.
Can you try using JAXB 2.2.4 based jars for IBM Java 1.7 and see if that solves the issue?
We had this issue after upgrading JAVA version from 1.6 to 1.8, to fix
you need to upgrade JAXB version from 1.x to 2.x.
Just had this problem
I was using Openj9 JDK and switched over to HotSpot. I used the IntelliJ JDK manager to download the JDK from OpenJDK and made my environmental variables point to the downloaded file structure (JAVA_HOME variable).
It solved the problem
This is not "real" answer, just a workaround suggestion.
The stack trace indicates you have a problem with schema generation. Maybe you could overcome this by providing an XML Schema explicitly using #XmlSchema.location. You'd have to generate and make this schema available manually. Not so cool, but if everything else fails...
Related
what would be the compatible weblogic versions for the log-2.17.1. any Reference link is useful.
part of my research nowhere i found related solutions in the official sites
It would be more the java version that weblogic runs on. If it supports java 8 then you would be able to use log4j 2.17.1. I think weblogic 12.1.3 onwards supports java 8.
Recently migrated from commons-lang-2.6 to commons-lang3.12.0, getting below error: org.apache.commons.lang.exception.NestableException
How to resolve that?
Facing this issue as apache has taken support from Nestableexception in commons-lang3
moreover your java version might be older. They have used java 5 in lowest version of commons-lang3, and in version: commons-lang3.12.0.jar, they have used java 8+
So, if you want to update commons-lang, need to upgrade jdk also. Thats the only solution.
https://commons.apache.org/proper/commons-lang/article3_0.html
(see under nested exception)
https://commons.apache.org/proper/commons-lang/download_lang.cgi
I have got jar compiled in java 1.8 from maximo dir and on my machine i have java 1.7 installed do i need to update my machine java before i run this jar. I can not run it before knowing this since it will get recorded in some logs and will update some server side files.
This is more of a Java question than a Maximo question, but no, it will not. You will get an "Unsupported major.minor version 52.0" if you do. This is not because of any features issue, this is simply because the bytecode is tagged as being from Java 8 and so earlier JREs will not run it.
Now this assumes you actually compiled the class files using Java 8, which probably only happened if you have custom code in there. If you are just using the out-of-the-box Maximo classes, those came pre-compiled (in I don't recall which version of Java) and so all you might have done was to bundle them into a jar, or more likely into the Maximo ear (since you don't run the businessobjects.jar). In that case, it doesn't matter what version of Java you used to created the jar/ear, it will run on any version of Java that is the same as or higher than whatever version IBM used to compile the code into classes.
According to groovy-eclipse plug-in website, groovy-eclipse plug-in supports certain groovy versions, 1.8, 2.0 and 2.1. This seemed a bit restrictive to me. What am I supposed to do if I work with groovy 1.9 or 1.7?
Perhaps the answer is that if you worked with Eclipse or GGTS before, then that couldn't happen; I suspect they never supported 1.9 or 1.7.
What is your concern? If you're worried that you might start off with 2.1 and have it not supported in future, then don't worry. If you're expecting to use some bizarre compiler feature that only worked in 1.9, then edit with the eclipse plugin for any version, and run Groovy (or Grails) from the command line with the right configuration.
Hope this helps...
Charles
Groovy-Eclipse supports the last couple of versions of groovy so we don't get into a maintenance headache. There is no Groovy 1.9 so we support right now 2.2/2.1/2.0/1.8 - we dropped 1.7. If you want to use 1.7 you would use an older version of groovy-eclipse that supported it. See version 2.8.0: http://groovy.codehaus.org/Groovy-Eclipse+2.8.0+New+and+Noteworthy - on that page you can download an update site archive that will give you groovy-eclipse and groovy 1.7.10
I need to build the jars for Hibernate 3.2.0 but I am having trouble finding directions. I am trying to follow along in the tutorial but it is wanting me to create classes and other files, is that really necessary just to compile the jars? I need to compile on a 64 bit Linux CentOS machine.
Also the directions in the tutorial are for 3.5 or 3.6 and they say to use maven but when I downloaded the source it came with a build.xml file, so am I supposed to use ant? and when I try ant it tells me I am missing antl/tools.
I am a brand new intern and I am just trying to figure this out so I can do what is asked of me. Any help would be greatly apprecited.
Thank You in advance.
For branch 3.2, you'll just need to run the run.sh (Linux) or run.bat (Windows). It should be enough. But keep in mind that 3.2 is an old branch. If you are developing a new application, consider using a newer version (3.6, for instance).
Binaries for Hibernate 3.2 can be downloaded from their SourceForge project page. Hibernate distributions typically contain hibernate3.jar, dependent jars, reference manuals and source files. The jars can be used on any JVM with version higher than 1.5 (or 1.4, I don't remember precisely) available on 64-bit CentOS.