I've been using com.sun.xml.bind.marshaller.NamespacePrefixMapper in my project, and i had no problem with it in JDK 6u17. Now I just updated to 6u18, and I saw that it has been replaced to com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper. However if I import this class and try to compile my classes, I get the error:
package com.sun.xml.internal.bind.marshaller does not exist
import com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper;
I can access this package through the NetBeans code completion feature, and NetBeans does not highlight the code for errors.
Any help would be appreciated!
I don't think that the class com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper is a replacement of com.sun.xml.bind.marshaller.NamespacePrefixMapper, the former is there for a long time and it NOT MEANT TO BE USED BY YOU AT ALL (hence the internal packaging).
The problem here is that JavaSE 6 doesn't have the JAXB RI (it has a JAXB implemenation but not JAXB RI) so if you want to rely on RI specific feature, you should bundle JAXB RI in your application (and that would protect you from JAXB changes in Java SE).
The NamespacePrefixMapper is not usable anymore.
Use the annotations in package-info.java:
#javax.xml.bind.annotation.XmlSchema(namespace = "http://nameSpaceUri"
, xmlns = {
#XmlNs(prefix = "myPrefix", namespaceURI = "http://nameSpaceUri")
}
, elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
package my.package.;
This works with the JAXB bundled with JDK7, for other JDK version update JAXB to 2.2.4.
You are not supposed to use com.sun.** classes directly. They are deemed to be internal and subject to change without notice. (And look what just happened!!) The fact that the new class has internal in the package name is an even bigger hint!
I strongly suggest that you look for a better way of doing what you are doing ... that doesn't use the com.sun.** classes.
EDIT - hmmm, looks like whoever is responsible for the JAXB RI has broken the Sun rules about package names for that extension! And it is also unfortunate that Sun has not implemented this particular RI extension in JDK 6.0.
Sun had made something not quite appropriate in this case. The namespace mapper isn't included in the spec, but it is "advertised" as a way to customize prefixes. So the general advice "don't use com.sun.*" doesn't apply here, and the javadoc of this class says:
Implemented by the user application to determine URI -> prefix mapping.
Check this article and see if it would work for you.
For those using maven, found including both JAXB-RI and JAXB for java6 via this link worked.
http://mvnrepository.com/artifact/com.googlecode.jaxb-namespaceprefixmapper-interfaces/JAXBNamespacePrefixMapper/2.2.4
I ran into this recently when porting some older code into a new project. The old project compiled just fine using ant, however the new one failed with the error you mention above.
After some digging, I found that the old build.xml file uses a javac compiler option to bypass the restriction above:
<javac srcdir="${srcDir}" destdir="${outputDir}" classpathref="classpath" debug="on">
<compilerarg value="-XDignore.symbol.file" />
</javac>
After finding it, I searched and found this other stackoverflow question:
Using internal sun classes with javac
The below post at stack overflow answers the question:
Define Spring JAXB namespaces without using NamespacePrefixMapper
Key is to include the rt.jar at build time and remove it from the application after compilation.
Adding this dependency to maven fixed it for me:
<dependency>
<groupId>com.googlecode.jaxb-namespaceprefixmapper-interfaces</groupId>
<artifactId>JAXBNamespacePrefixMapper</artifactId>
<version>2.2.4</version>
</dependency>
For me, using JBoss, the fix required explicitly adding a line to WEB-INF/jboss-deployment-structure.xml
JBoss AS7 has a class loading mechanism which is different from previous versions.
Add the line '', in the structure like so:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<deployment>
<dependencies>
<module name="com.sun.xml.bind" />
</dependencies>
</deployment>
</jboss-deployment-structure>
Related
I got a Java project that I'm migrating from Java 8 to Java 13. This project uses ResourceBundles to enable language localisation.
In Java 8, I provided a custom ResourceBundle.Control to ResourceBundle.getBundle(baseName, control) but this doesn't work anymore in Java 9+. As I understand it, I must instead provide a custom ResourceBundleProvider interface, which I called UiProvider, and an implementation of this interface, UiProviderImpl, which must be used as a service.
To generate module descriptors, I'm using the moditect maven plugin. But it doesn't look like I can add a provides directive anywhere, only exports, opens and uses directives. Or am I missing anything? Here's an excerpt of my pom.xml with what I tried to configure. Can this be fixed?
<module>
<moduleInfo>
<name>net.babelsoft.negatron</name>
<opens>net.babelsoft.negatron;</opens>
<uses>theme.language.spi.UiProvider</uses>
<provides>theme.language.spi.UiProvider with theme.language.spi.UiProviderImpl</provides>
</moduleInfo>
</module>
At the time I wrote my question, Moditect didn't support the provides directive within the moduleInfo tag.
The only way was to use a moduleInfoSource tag, which forces the developper to directly write the actual content of module-info.java, not very satisfactory.
After discussing with the author of Moditect, I submitted a pull request to add the support of the provides directive within the moduleInfo tag. It hasn't been merged to Moditect source code yet...
When building apache-camel with openJDK-11. There are a lot of missing dependencies like
* jaxb
* annotation
* ...
How to build apache-camel source code with openJDK?
Officially there is no documentation on how to build using openJDK; Is there is any way to force build it?
I have tried adding jaxb implementation for server like "org.eclipse.persistence.moxy" but the same wasn't picked up properly :(
I have restricted the build env to be only open source; hence using openJDK as the base for development.
According to this article https://blog.codefx.org/java/java-11-migration-guide/ several packages have been removed from JDK 11.
In particular the section called Migrating From Java 8 To Java 11 shed some light on how to deal with this.
In short the following packages were removed:
The JavaBeans Activation Framework (JAF) in javax.activation CORBA in the packages javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.*
The Java Transaction API (JTA) in the package javax.transaction
JAXB in the packages javax.xml.bind.*
JAX-WS in the packages javax.jws, javax.jws.soap, javax.xml.soap, and javax.xml.ws.*
Commons Annotation in the package javax.annotation
To fix this:
Add third-party dependencies that contain the classes you need. The easiest way to do that is to stick to the reference implementations (given as Maven coordinates without version – use the most current ones):
JAF: with com.sun.activation:javax.activation
CORBA: there is currently no artifact for this
JTA: javax.transaction:javax.transaction-api
JAXB: com.sun.xml.bind:jaxb-impl
JAX-WS: com.sun.xml.ws:jaxws-ri
Commons Annotation: javax.annotation:javax.annotation-api
You can also view some more information using this Stackoverflow answer
Netbeans seems to reject some XSD tags supported by XSD 1.1, for example "assert":
cvc-complex-type.2.4.a : Invalid content found from the element
'xs:assert'. One of the values
'{"http://www.w3.org/2001/XMLSchema":attribute,
"http://www.w3.org/2001/XMLSchema":attributeGroup,
"http://www.w3.org/2001/XMLSchema":anyAttribute}' is expected. [205]
I tried to use some of these examples without success. What can I do to resolve my problem?
As far as I know, I have nothing to do to specify in the XSD schema that I use some features of XSD 1.1:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
It depends exactly what you mean by "use XSD 1.1 in NetBeans 8.2", but I assume you want to use the context menu entry Validate XML in NetBeans against some *.xsd file with XSD 1.1 features (such as assert). If I do that I see the same "cvc-complex-type.2.4.a : Invalid content found..." error that you report.
There is no way to customize the validator used by the Validate XML command, and apparently it uses the JDK's javax.xml API for validation. NetBeans 8.2 uses Java 8, but even with JDK 9 there is no way to validate XSD 1.1 features:
Java 9.
...The big news is that finally we get the internal ports of Xerces
updated. Oracle (and Sun before them) have been really slack in
neglecting this so long: Java was stuck using Xerces 2.7.n for 11
years for goodness sake. The new ports are equivalent to Apache
Xerces 2.11.0. (NOTE: XSD is still 1.0 only, the XSD 1.1 updates have
not been put in place, but this probably reflects Apache Xerces’ slow
pace to make the changes official.)
The same problem occurs when using Apache NetBeans 9.0 RC1 so this issue will probably not get resolved until either:
NetBeans uses a JDK which uses a version of Xerces that supports the validation of XSD 1.1 features.
NetBeans uses a different approach for XSD validation.
I also don't see any NetBeans plugins that will help. Of course there are still third-party tools and (possibly) configuration for Maven projects that may help, but I don't see a solution using only NetBeans.
I would like to use the Optional class of guava jar. I am able to use it in my project.But, in the gwt-dev jar the Optional class has already been there in the package com.google.gwt.thirdparty.guava.common.base.Optional. So, I don't want to use the guava jar for just using the Optional class. So, I am trying to use the Optional class of gwt-dev jar.
Steps which I have done:
I have created com.google.gwt.thirdparty.guava.common.base package in my project
In that package I have created the Base.gwt.xml file.
<?xml version="1.0" encoding="utf-8"?>
<!-- semi-autogenerated module descriptor -->
<module>
<source path="">
</source>
</module>
I have included the Base.gwt.xml file in my gwt.xml file.
Though I have done the above steps I was not able to compile the code. I am getting the below exception:
No source code is available for type com.google.gwt.thirdparty.guava.common.base.Optional; did you forget to inherit a required module?
Any suggestions would be appretiated.
You shouldn't be using com.google.gwt.thirdparty.* - those are internally repackaged jars. There's no guarantee they'll be there in the next version of GWT - in fact, I'd expect them (at least the Guava part) to be removed in favor of "vanilla" Guava, as suggested in this thread. To further reinforce this there's no source attached for them in the gwt-dev.jar (as you've experienced), so you can't use them in your client-side code.
Please use the normal dependency on Google Guava - the GWT compiler will only compile in the parts of Guava that you are using (especially if you just inherit com.google.common.base.Base) and prune out the rest.
I have updated our projects (Java EE based running on Websphere 8.5) to use a new release of a company internal framework (and Ejb 3.x deployment descriptors rather than the 2.x ones). Since then my integration Tests fail with the following exception:
[java.lang.ClassNotFoundException: com.ibm.xml.xlxp2.jaxb.JAXBContextFactory]
I can build the application with the previous framework release and everything works fine.
While debugging i noticed that within the ContextFinder (javax.xml.bind) there are two different behaviours:
Previous Version (Everything works just fine): None of the different places brings up a factory class so the default factory class gets loaded which is com.sun.xml.internal.bind.v2.ContextFactory (defined as String constant within the class).
Upgraded Version (ClassNotFound): There is a resource "META-INF/services/javax.xml.bind.JAXBContext" beeing loaded successfully and the first line read makes the ContextFinder attempt to load "com.ibm.xml.xlxp2.jaxb.JAXBContextFactory" which causes the error.
I now have two questions:
What sort is that resource? Because inside our EAR there is two WARs and none of those two contains a folder services in its
META-INF directory.
Where could that value be from otherwise? Because a filediff showed me no new or changed properties files.
No need to say i am going to read all about the JAXB configuration possibilities but if you have first insights on what could have gone wrong or help me out with that resource (is it a real file i have to look for?) id appreciate a lot. Many Thanks!
EDIT (according to comments Input/Questions):
Out of curiosity, does your framework include JAXB JARs? Did the old version of your framework include jaxb.properties?
Indeed (i am a bit surprised) the framework has a customized eclipselink-2.4.1-.jar inside the EAR that includes both a JAXB implementation and a jaxb.properties file that shows the following entry in both versions (the one that finds the factory as well as in the one that throws the exception):
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
I think this is has nothing to do with the current issue since the jar stayed exactly the same in both EARs (the one that runs/ the one with the expection)
It's also not clear to me why the old version of the framework was ever selecting the com.sun implementation
There is a class javax.xml.bind.ContextFinder which is responsible for initializing the JAXBContextFactory. This class searches various placess for the existance of a jaxb.properties file or a "javax.xml.bind.JAXBContext" resource. If ALL of those places dont show up which Context Factory to use there is a deault factory loaded which is hardcoded in the class itself:
private static final String PLATFORM_DEFAULT_FACTORY_CLASS = "com.sun.xml.internal.bind.v2.ContextFactory";
Now back to my problem:
Building with the previous version of the framework (and EJB 2.x deployment descriptors) everything works fine). While debugging i can see that there is no configuration found and thatfore above mentioned default factory is loaded.
Building with the new version of the framework (and EJB 3.x deployment descriptors so i can deploy) ONLY A TESTCASE fails but the rest of the functionality works (like i can send requests to our webservice and they dont trigger any errors). While debugging i can see that there is a configuration found. This resource is named "META-INF/services/javax.xml.bind.JAXBContext". Here are the most important lines of how this resource leads to the attempt to load 'com.ibm.xml.xlxp2.jaxb.JAXBContextFactory' which then throws the ClassNotFoundException. This is simplified source of the mentioned javax.xml.bind.ContextFinder class:
URL resourceURL = ClassLoader.getSystemResource("META-INF/services/javax.xml.bind.JAXBContext");
BufferedReader r = new BufferedReader(new InputStreamReader(resourceURL.openStream(), "UTF-8"));
String factoryClassName = r.readLine().trim();
The field factoryClassName now has the value 'com.ibm.xml.xlxp2.jaxb.JAXBContextFactory'
Because this has become a super lager question i will also add a bounty :)
I will work the entire day on this and let you know if there is any news.
Update/ Solution
This question has been solved. The original problem has occured because misconfiguration of complexly build multi model maven projects which one dependency used a updated version of a customized eclipse link jar that contained a definition for a JAXBFactory not available in the component where the error occured. Setting the JAXB context factory in most cases is configured with a jaxb.propertie file or JAXBContext file that contains the same definition. Detailed loading process of the appropriate JAXBContextFactory happens in javax.xml.bind.ContextFinder.
The error has not yet been solved (during the fact over 4 major EE/SE Applications lead to the error) and there is no general answer but that defined JAXBContextFactorys must exist in your classpath (wow what a wonder...) so you either have a that ClassNotFound Error because youre missing resources (well thats the acctual cause) or because you have a wrong JAXBContextFactory defined in any of the above mentioned propertie files which contain a definition according to the below answer.
Very many thanks for your great comments and support, i realy appreciate!
You can include a jaxb.properties file in the same package as your domain model to specify the JAXB (JSR-222) implementation you wish to use. For example it would look like the following to specify EclipseLink MOXy as your JAXB provider.
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
For More Information
http://blog.bdoughan.com/2011/05/specifying-eclipselink-moxy-as-your.html
Another quick and dirty solution (a workaround, really) that worked for me is to explicitly include a JAXB implementation to the maven build. For example
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.2.7</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.2.7</version>
</dependency>
Note that this adds a somehow unnecessary dependency to your build, as JAXB obviously already is part of each JRE >= version 6.
Most likely this will only work when the WAS classloader is set to parent last.