I'm having a Problem with a Java program that I am developing that is using a jar file that was created by the Mathworks JA builder. In this Matlab program, it is using JAK to create a KML file for Google Earth. I have had no problem on the development computer with the full Matlab ide. However when taken over to another machine that only has the MCR I get the following error:
javax.xml.bind.PropertyException: name: com.sun.xml.bind.namespacePrefixMapper value: de.micromata.opengis.kml.V_2_2_0.kml$NameSpaceBeautyfier#15cb235
at javax.xml.helpers.AbstractMarshallerImpl.setProperty(Unkown Source)
at com.sun.xml.internal.bind.V2.runtime.MarshallerImpl.setProperty(Unkown Source)
at de.micromata.opengis.kml.V_2_2_0.kml.createMarshaller(kml.java:642)
at de.micromata.opengis.kml.V_2_2_0.kml.marshal(kml.java:682)
Is this something that is related to the Classpath?
Thanks for any help.
Do you have the same version of the JAXB libraries on both systems? Looks like it might be a versioning conflict. Searching on your error I came across this page: http://timepassguys.blogspot.com/2011/12/jaxb-exception-javaxxmlbindpropertyexce.html
Maybe that solution is something you can try?
You are using the JAXB implementation that is included in the JDK (com.sun.xml.internal.bind), but are specifying the property for the Metro JAXB implementation (com.sun.xml.bind). Note that Metro JAXB undergoes a package rename when it is included in the JDK.
Options
You could use the com.sun.xml.internal.bind.namespacePrefixMapper property.
You could use a jaxb.properties file to specify the use of the Metro JAXB implementation.
For More Information
http://blog.bdoughan.com/2011/11/jaxb-and-namespace-prefixes.html
http://blog.bdoughan.com/2011/05/specifying-eclipselink-moxy-as-your.html
Related
I am working on migration my application to java9, I found that I can set Add-Opens in my manifest file to open some java internal packages for reflection usage. I am thinking fields like Add-Opens are only support after java9, so I wonder what will happen if I run it using lower version like java8. Will those unrecognized fields (general unrecognized fields not specific to Add-Opens) in the manifest file be ignored in java8? What impact they can have on the application when running on java8? Thank you.
Thanks for VGR's comment, this link for oracle official document on manifest states that Attributes which are not understood are ignored. Such attributes may include implementation specific information used by applications.
Reference: https://docs.oracle.com/en/java/javase/18/docs/specs/jar/jar.html#overview
I want to use the the class 'com.sun.tools.jxc.SchemaGenTask' to generate xsd from java. However, when I tried to download the glassfish version or the sun-version of the library jaxb-xjc (version number 2.11/2.12) I could not find the class. Is the class moved? Should I use a different library? I have moved back to an older version of jaxb-xjc where I can find it (2.2.7).
It's now in the library jaxb-jxc, under the same group ID com.sun.xml.bind. Its documentation is here.
I am taking the input from the web, which is an Xml file and converting into a Json data using the library json-lib . I have created a user library and added the following jars into it:-
json-lib-2.3-jdk15.jar
commons-collections.jar
commons-lang.jar
commons-logging.jar
commons-beanutils.jar
ezmorph-1.0.6.jar
xom-1.1.jar
But still gives the following error:-
08-04 13:58:31.642: ERROR/dalvikvm(484): Could not find class 'net.sf.json.xml.XMLSerializer$CustomElement', referenced from method net.sf.json.xml.XMLSerializer.addNameSpaceToElement
Can anyone help me out in resolving this issue.
Either you have a sdk level / jdk level conflict. I mean dalvik can't get the byte code of the CustomElement class of your librairy as it is compiled with to recent features for your SDK like annotations for instance.
Or there is a conflicting librairy json-lib in some other of your jars or lib folders.
(the 3 first comments are not relevant, it's just the way inner classes are compiled, using a $)
Regards,
Stéphane
Since android already support json org.json a different json library may conflict. (You can download the jar here)
Try to use this library instead of an external library on android.
BTW: You can also use this library if you need on any java code (not only android)
I'm creating a WSDL first webservice with JAXB and CXF. I do not own the WSDL, so I cannot make changes to it. I'm using ftp://ftp.ihe.net/TF_Implementation_Material/ITI/wsdl/PIXManager.wsdl as my WSDL. I used CXF 2.3.0 to generate Java classes.
Java class generation went fine, but when I'm trying to run this in a web application, I get an error
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 17 counts of IllegalAnnotationExceptions
The 17 counts are of the format
There's no ObjectFactory with an #XmlElementDecl for the element {urn:hl7-org:v3}assignedDevice.
this problem is related to the following location:
at protected javax.xml.bind.JAXBElement org.hl7.v3.QUQIMT021001UV01AuthorOrPerformer.assignedDevice
When I go to the class mentioned, i.e. QUQIMT021001UV01AuthorOrPerformer and look at the field assignedDevice, I see this
#XmlElementRef(name = "assignedDevice", namespace = "urn:hl7-org:v3", type = JAXBElement.class)
protected JAXBElement<COCTMT090300UV01AssignedDevice> assignedDevice;
When I look at the ObjectFactory of the package, I see this
private final static QName _COCTMT090303UV01AssignedDeviceAssignedDevice_QNAME = new QName("urn:hl7-org:v3", "assignedDevice");
All my 17 errors are similar. What can I do during my codegen or runtime in order to get my service work?
What Java version are you using at run-time? I had a similar issue with OTA schema when running with Java 6. I eliminated the problem by making the following changes to the Maven configuration:
Use JAXB impl 2.1.* (instead of 2.2) with provided scope, to match JAXB version included in Java 6.
Use JAX-WS 2.1 (instead of 2.2) to match Java 6 and JAXB 2.1.x.
Add the option frontEnd to the Maven cxf-codegen-plugin plug-in and set it to jaxws21 (or if using wsdl2java on command line, use "-fe jaxws21" option).
When you generate the classes, you also generate a file called jaxb.properties. Make sure this file is accessible to the application at runtime.
I had the same problem and it was due to maven packaging: maven will not include in the package resource files (like jaxb.properties) that are below the src/main/java tree unless specifically instructed to do so. I did this using the org.codehaus.mojo:build-helper-maven-plugin with the add-resource goal.
Hope this helps
I Faced this similar error and the reason was having conflicts between the webservices generated stub java classes.
if above answers does not work , try look for conflicts.
add one stub at a time and add incrementally.
hope it helps
I had a nifty small tool written to convert spreadsheets to plain text.
Since it was my private hacker tool, it relied on OpenOffice 2.x to read the files.
But when I installed OpenOffice 3 and tried to get it get it to run, I failed miserably, because I'm either missing some JAR files or half the classes have been replaced.
I'm including all five JAR files from URE/Java (URE: UNO
Runtime Environment, a subset of OpenOffice.org hosting and
managing UNO components) and am still missing these classes:
com.sun.star.frame.XComponentLoader
com.sun.star.frame.XController
com.sun.star.frame.XDesktop
com.sun.star.frame.XModel
com.sun.star.frame.XStorable
com.sun.star.sheet.XSpreadsheet
com.sun.star.sheet.XSpreadsheetDocument
com.sun.star.sheet.XSpreadsheetView
com.sun.star.text.XTextDocument
Any pointers?
I found what I was missing.
I had to include the following jars
URE/java/juh.jar
URE/java/jurt.jar
URE/java/ridl.jar
Basis/program/classes/unoil.jar
The last one I was missing before - note the German OOo version.
And, something I didn't have to do before, I had to include the path to the OOo executables, e.g.
c:/program/OpenOffice.org 3/program/
After that and without changing code it worked just like before.
So, Brian, UNO's API is stable even between major releases. It was just the classpath I had to fix.