How to use XSD 1.1 in Netbeans 8.2? - java

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.

Related

Is apache-camel source code buildable in open-jdk-11?

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

How to create service first soap webservice using spring-boot

We can see many tutorials that shows how to produce soap webservice using xsd in spring-boot. Is it possible to create soap webservice without xsd and from plain Java code using spring-boot-webservice module like we do using #webservice annotation in jax-ws
Guides like this start with an xsd file because they use xjc to create java classes from the XSD definition. xjc creates classes with JaxB annotations (javax.xml.bind.annotation). JaxB is an xml binding specification that has been part of the JDK since 1.6, and it requires that all types from the xsd exist as java classes.
I suggest that you do a tutorial that starts with an xsd an take a look at the auto generated classes. There is nothing to prevent you from writing you own classes instead of generating them from a wsdl, and if you don't refer to external schemas I prefer to do the code only approach (I hate xml configuration).
If you look at the tutorial, the gradle task "getJaxb" will create .java files into "build/generated-sources" compile them and copy them into "build/classes" if you copy the *.java files into "src/main/java" (keep the package structure) and delete delete/disable the "genJaxb" task in gradle, and delete your build folder, everything still works (it actually works better since you normally have red lines in your IDE because the XML beans don't exist until you run the generator the first time).
Now all you need to do is master the JaxB annotations, so you can write your own beans.

"Use <jaxb:property> to resolve this conflict" error while converting xsd to java objects using jaxb

I am trying to unmarshall elements of xds file to java oblects. I am using Jaxb mavan plugin and Eclipse IDE.
My .xsd file is can be found from
EiPayload
EiEnrollment
EiClasses
Here is my file structure and error,
Need some help to debug this error..!
Disclaimer: I am a lead dev of the ogc-schemas and the w3c-schemas projects.
You have problems with GML 3.2.1 and XLink 1.0. I've implemented bindings for these schemas in the ogc-schemas and the w3c-schemas project. Here you go:
gml-v_3_2_1.xjb
xlink-v_1_0.xjb
But better use the provided JAR artifacts as episodes.

XMLBeans - xsi:type stripped using Axis2 and Tomcat?

I’m new to XMLBeans and have been trying to use it to create an XML document as part of an axis2 web service. When I run my code as a standard Java application or as a standard servlet, the XML is correctly generated:
<?xml version="1.0" encoding="UTF-8"?>
<c:BroadsoftDocument protocol="OCI" xmlns:c="C">
<sessionId>000000001</sessionId>
<command xsi:type="AuthenticationRequest" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<userId>admin</userId></command>
</c:BroadsoftDocument>
However, when the exact same code is run under Axis2 & Tomcat in a servlet I get:
<?xml version="1.0" encoding="UTF-8"?>
<c:BroadsoftDocument protocol="OCI" xmlns:c="C">
<sessionId>000000001</sessionId>
<command>
<userId>admin</userId></command>
</c:BroadsoftDocument>
This of course isn’t valid – the xsi:type of the “command” element is stripped when the code is run under Tomcat.
Does anyone have any suggestions of what I could be doing wrong that would cause this type of issue only when running under Axis2? At first I thought it was a Tomcat issue, but after creating a generic servlet and running the exact same code I don't have any issues. I've tried playing with the XMLOptions for XMLBeans, but couldn't seem to resolve the problem. The options I'm currently using are:
xmlOptions = new XmlOptions();
xmlOptions.setCharacterEncoding("UTF-8");
xmlOptions.setUseDefaultNamespace();
xmlOptions.setSaveAggressiveNamespaces();
xmlOptions.setSavePrettyPrint();
It turn out the issue is with the class loader order that Axis2 uses. This was patched and the functionality is described here:
http://marc2.theaimsgroup.com/?l=axis-cvs&m=115946726426905&w=3
Long story short, to resolve this issue you need to edit the "services.xml" for your Axis2 project and add:
<parameter name="ServiceTCCL">composite</parameter>

What happened to JAXB's NamespacePrefixMapper in JDK6u18

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>

Categories