I'm using Workshop for Weblogic and I'm testing an XQuery Transformation.
Both MFL and XSD are valid. But the XQuery doesn't seem to work... it gives me this error:
Error occurred while executing XQuery: loader constraint violation: when resolving method "javax.xml.stream.XMLInputFactory.createXMLStreamReader(Ljava/io/Reader;)Ljavax/xml/stream/XMLStreamReader;" the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, weblogic/xml/query/parsers/StAXCursorAdaptor, and the class loader (instance of ) for resolved class, javax/xml/stream/XMLInputFactory, have different Class objects for the type javax/xml/stream/XMLStreamReader used in the signature
Have you ever seen this before? How can I solve this please?
You need to reinstall workshop with default JRockit, or what is much faster just edit workshop.ini and change -vm parameter value from Sun/Oracle JDK to JRockit SDK which can be found in weblogic directory.
Related
Up until now, I had been using the following libraries:
kotlin("jvm")
kotlin("plugin.serialization") version "1.7.10"
implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.3.2")
Since until now, there is no serializer for the type kotlin.time.Duration, I had my own custom serializer. So far so good.
Now I want to update the kotlinx serialization libraries to 1.4.0, which has a DurationSerializer.
When I do this, the compiler naturally protests the following:
Caused by: java.lang.IllegalArgumentException: The name of serial descriptor should uniquely identify associated serializer. For serial name Duration there already exist DurationSerializer.
So I delete my custom DurationSerializer in order to use the new one included in the library, clean and attempt to recompile. However, when I do that, the following happens:
Serializer has not been found for type 'Duration'. To use context serializer as fallback, explicitly annotate type or property with #Contextual
Basically, the new library version can tell that my custome DurationSerializer is conflicting with its own, but then can't actually use its own. How do I get around this?
Got the answer from the kotlinx.serialization github repository here.
Turns out the library version of the serializer will only be added in a future compiler update.
In the meantime, our serial name for the custom serializer was too similar to the libraries', causing a conflict. Changed it from kotlin.time.Duration to CustomDurationSerializer and the issue went away.
I am currently facing an issue about Xamarin Forms Android Bindings library.
I've put a .jar library inside my bindings project and I realize that the library is not fully loaded.
When I build my bindings project it compiles properly but I still have some warnings in my output.
1>BINDINGSGENERATOR : warning BG8102: Class Java.Util.LinkedHashMap has unknown base type Java.Util.HashMap.
1>BINDINGSGENERATOR : warning BG8103: Class Com.MyParams has invalid base type java.util.LinkedHashMap.
1>BINDINGSGENERATOR : warning BG8701: Invalid return type com.MyParams in method GetParams in managed type Com.TagOp.
1>BINDINGSGENERATOR : warning BG8801: Invalid parameter type com.MyParams in method TagOps in managed type Com.TagOp.
1>BINDINGSGENERATOR : warning BG8801: Invalid parameter type com.MyParams in method TagOps in managed type Com.TagOp.
1>BINDINGSGENERATOR : warning BG8801: Invalid parameter type com.MyParams in method TagPage in managed type Com.Tag.
In my Android code I can't use the Com.MyParams class because it's not loaded.
This problem occurs since the update of Xamarin for Visual Studio 2017.
Do you have any leads to solve this problem ? Thanks in advance.
HashMap & LinkedHashMap are not known ...therefore nothing based upon them can be instanced.
When the data-binding does not know a class, then it either lacks the annotations, it might not extend class BaseObservable and/or has wrongful get / set method names (which need to match the name of the field); there are quite a few conditions to meet, depending if one-way or two-way data-binding is required. Reviewing the generated code often gives a clue what one has to change.
However, directly data-binding the JAR classes does not even appear possible, unless adding the required annotations into them and then building the JAR, in order to have them bind-able. The documentation of the Android Data Binding Library and Xamarin Java Bindings Metadata explains it (replicating the required Java classes from scratch, perfectly bind-able, might be the most fast-forward, if not the only way).
One can only work around it, by substituting the classes to be bound to the GUI - which is possible with rather simple classes, or when using a Java decompiler (in order to know the fields to use).
We have recently migrated to Jboss EAP 6.4 from Jboss 4.2. In one of our EJB classes we are having over loaded methods create(AbstractBean) and create(AbstractEntity). The class AbstractEntity is extending AbstractBean class. When we try to invoke the create(AbstractBean) method in Jboss 6.4 instance we are getting the IllegalArgumentException: argument type mismatch error, but we are not getting this exception in Jboss 4.2.
When we comment out the create(AbstractEntity) method, the exception is not occurring, also when we try to invoke the method using reflection the exception is not occurring.
But we just wanted to know is there anything to be done in the server configuration to resolve this issue or as mentioned above using reflection is a correct solution.
Can anyone help us understand the Jboss6.4 behavior correctly.
We were having two methods in a class which having different arugment type but argument type of one method extends argument type of other so JBoss ended up with ambiguity error. we have removed the method with derived class as argument and kept the super class one. That resolved the issue for us.
I am facing an issue related to linkage when i deployed my application websphere 8.5
Error in the XML parsing of the included Input Stream: java.lang.LinkageError: loading constraint violation when resolving method "javax/xml/parsers/SAXParser.parse(Lorg/xml/sax/InputSource;Lorg/xml/sax/helpers/DefaultHandler;)V" : loader "com/ibm/ws/classloader/CompoundClassLoader#aa54261e" of class "com/XMLParser/CreateParser" and loader "com/ibm/oti/vm/BootstrapClassLoader#1c4565b7" of class "javax/xml/parsers/SAXParser" have different types for the method signature.
I have the following jars in my class path.
I have set the loader to PARENT_LAST.
I tried to debug the class alone using a main method and found that it is taking the impl of saxparser of jdk 1.5 rt.jar and it is working as expected. After deploying the ear it is throwing the exception while the code hits the SAXParser.parse(InputSoruce,DefaultHandler) method.
jaxb-impl 2.2.6,
jaxb-libs-1.0.5,
jaxb-xjc-2.0EA3,
dom4j-1.1,
sax 2.0.1
Does any one have any idea about this problem?
Your class loader has visibility to two copies of org.xml.sax. The first because you've included the SAX APIs in your PARENT_LAST class loader, and the second indirectly via javax.xml.parsers in the JRE. You either need to remove the SAX API JAR from your application or you need to add the javax.xml (and perhaps more) APIs + impl to your application.
When starting WebSphere, I get this exception:
Could not instantiate bean class [org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter]:
Constructor threw exception; nested exception is java.lang.ClassCastException:
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl incompatible with
javax.xml.transform.TransformerFactory
Caused by: java.lang.ClassCastException: com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
incompatible with javax.xml.transform.TransformerFactory
at javax.xml.transform.TransformerFactory.newInstance(Unknown Source)
at org.springframework.http.converter.xml.AbstractXmlHttpMessageConverter.<init>(AbstractXmlHttpMessageConverter.java:47)
at org.springframework.http.converter.xml.SourceHttpMessageConverter.<init>(SourceHttpMessageConverter.java:45)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.<init>(AnnotationMethodHandlerAdapter.java:197)
This doesn't seem have any impact on any beans in my applicationContext.xml but it's still odd. For me, this looks as if IBM classes are leaking into my application.
How can I fix this? I already set the option "Access to internal server classes" to "Restrict".
It was indeed a class-loading issue, however this cannot be solved by changing class-loader settings.
The problem was that the xml-apis and javax.xml jars were being imported over some maven dependencies.
Since we already set the class loader policies for the application to PARENT_LAST, the javax.xml.transform.TransformerFactory was being loaded from the WebApp-Class loader from our jar files.
However its implementation 'com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl' was coming from the server class loader, this one was linked to the javax.xml.transform.TransformerFactory provided by the JDK/JRE.
Since the classes were loaded from different sources a ClassCastException was thrown.
Removing all dependencies to xml-apis / xerces / javax.xml jars solved the problem.
Since these APIs are now part of the JDK they no longer need to be imported.
... and if you wonder why I know so much about this issue: I work together with Aaron. ;)
I can't speak for Restrict as I have no personal experience with it,But I think the problem is more to do with IBM Class Loader. The class you are referring to is part of IBM Java implementation of TransformerFactory, I think you can try one of the following to solve this issue on hand
Either change the server class loader policy to PARENT_LAST (This way class loader will find the class from application's local class path, before going to up the chain all the way to java run time)
The other option would be look at the jaxp.properties file, I think it is located in (was_root\java\jre\lib), I only read about this option never actually used it
Why do you say IBM classes are leaking into your application?
The TransformerFactory is asked to create a newInstance. It follows a sequence of steps to determine which TransformerFactory to use. If none of the config is specified, it simply chooses to use the default factory.
Here is the javadoc for TransformerFactory:
http://download.oracle.com/javase/1.5.0/docs/api/javax/xml/transform/TransformerFactory.html#newInstance()
What is the OS ? Is that AIX?
http://www.ibm.com/developerworks/java/jdk/aix/j664/sdkguide.aix64.html
Looking at this doc (link above) for AIX it tells me that this is the default Impl:
javax.xml.transform.TransformerFactory
Selects the XSLT processor. Possible values are:
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
Use the XL TXE-J compiler. This value is the default.
Post back additional information so that we can try and troubleshoot this.
HTH
Manglu