[JAXB-1075] Add flag to allow missed CPluginCustomization.markAcknowledged() to emit warnings instead of failing the execution. Created: 23/May/15  Updated: 23/May/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: jahutton Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As far as I can tell there is no reason (and no requirement in the spec) to error if the CPluginCustomization.markAcknowledged() of a plugin is not invoked. If the goal is to notify the user so that they can evaluate any missed customizations, then it should be emitted as a warning/info. Otherwise what this leads to are a bunch of custom jaxb plugins that just mark everything as acknowledged. Having this as an option would allow users who feel it necessary to error out to keep this behavior.






[JAXB-1027] NullPointerException with @XmlRootElement and @XmlValue Created: 22/Jun/14  Updated: 22/May/15

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tmjee1 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This happens with the jaxb version that comes bundled with jdk8

@XmlRootElement("obj1")
public class Object1

{ @XmlElementRef public Object2 object2 }

@XmlRootElement("obj2")
public class Object2

{ @XmlValue public String val; }

the above would trigger
Exception in thread "main" java.lang.NullPointerException
at com.sun.xml.internal.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:113)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:166)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:488)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:305)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:462)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584)



 Comments   
Comment by rpmcfong [ 13/May/15 ]

I encountered this issue today on Java 1.8.0_40 and took a look through the source code for 2.2.11. It looks like it would work if we didn't consider it a leaf node.

One fix would require com.sun.xml.bind.v2.runtime.property.PropertyFactory.create line 124 to return false. This would allow line 126 to find propImpls[7] which is SingleReferenceNodeProperty.class. Alternatively, we could add SingleReferenceNodeProperty​ to propImpls[1].

Are there side effects to this suggestion?

Comment by Iaroslav Savytskyi [ 22/May/15 ]

I've spent some time trying to understand why it's working like this.
The problem is in @XmlElementRef -> @XmlValue combination. It seems to be valid combination even if XJC is not generating such case in this way.

Comment by Iaroslav Savytskyi [ 22/May/15 ]

@rpmcfong: the side effect is that generated XML is not correct





[JAXB-1074] Jaxb generated corrupted XML(Intermittent) file during marshalling eventhough validated against XSD, but rerunning the job suceeded Created: 09/May/15  Updated: 21/May/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mayuran19 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

Solaris 10, JDK 1.7,NFS file system



 Description   

We are having some issue with XML file generation using JAXB. Even though the marshalling is successfully completed the generated XML file is corrupted sometimes(Everyday we generate around 200 xml files each is 150MB in size, so far only 2 files are corrupted in two months).

There were no errors reported in the log file(catalina.out) even though we log each exceptions.

But when we rerun the job, the files are generated successfully.

The marshaller is used by multiple threads at the same time, we have already checked the spring code that for every call of marshall, spring create new marshaller object. So we ruled out the concurrency issue.

private void write(Object obj, XmlOutput out, Runnable postInitAction) throws JAXBException {
try {
if( obj == null )
throw new IllegalArgumentException(Messages.NOT_MARSHALLABLE.format());

if( schema!=null ) {
// send the output to the validator as well
ValidatorHandler validator = schema.newValidatorHandler();
validator.setErrorHandler(new FatalAdapter(serializer));
// work around a bug in JAXP validator in Tiger
XMLFilterImpl f = new XMLFilterImpl() {
@Override
public void startPrefixMapping(String prefix, String uri) throws SAXException

{ super.startPrefixMapping(prefix.intern(), uri.intern()); }

};
f.setContentHandler(validator);
out = new ForkXmlOutput( new SAXOutput(f) {
@Override
public void startDocument(XMLSerializer serializer, boolean fragment, int[] nsUriIndex2prefixIndex, NamespaceContextImpl nsContext) throws SAXException, IOException, XMLStreamException

{ super.startDocument(serializer, false, nsUriIndex2prefixIndex, nsContext); }

@Override
public void endDocument(boolean fragment) throws SAXException, IOException, XMLStreamException

{ super.endDocument(false); }

}, out );
}

try

{ prewrite(out,isFragment(),postInitAction); serializer.childAsRoot(obj); postwrite(); }

catch( SAXException e )

{ throw new MarshalException(e); } catch (IOException e) { throw new MarshalException(e); }

catch (XMLStreamException e)

{ throw new MarshalException(e); }

finally

{ serializer.close(); }

} finally

{ cleanUp(); }

}

private void cleanUp() {
if(toBeFlushed!=null)
try

{ toBeFlushed.flush(); }

catch (IOException e)

{ // ignore }
if(toBeClosed!=null)
try { toBeClosed.close(); } catch (IOException e) { // ignore }

toBeFlushed = null;
toBeClosed = null;
}

I don't understand why the ioexception is being ignored in the cleanup method.



 Comments   
Comment by Iaroslav Savytskyi [ 11/May/15 ]

Thanks for reporting.
I'll add logging there.

Comment by mayuran19 [ 11/May/15 ]

Hi laroslav savytskyi,
Thanks for your reply.

Is it possible to confirm that the said issue have real impact if NFS file system is not stable?
So that I can concentrate on work around for the issue.
Otherwise I need to continue the investigation in other areas such as concurrency.

Thanks,
Mayuran

Comment by Iaroslav Savytskyi [ 21/May/15 ]

Hi,

As you've said every marshaller is used by one thread. So it couldn't be concurrency issue.

My proposition is to patch given code with some logging and test it. To do this you will need to checkout standalone JAXB, patch, build and use.

GIT: git://java.net/jaxb~v2
Build: mvn clean install

Don't forget to put jaxb-api.jar to endorsed folder.

Comment by mayuran19 [ 21/May/15 ]

Hi,

Thanks for the update.
I will checkout and build.

Regards,
Mayuran





[JAXB-614] JAXB generates illegal XML characters Created: 18/Mar/09  Updated: 13/May/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: ranboii Assignee: Martin Grebac
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?threadID=59068


Issuezilla Id: 614

 Description   

Some characters (such as 0x1f) that are legal in Java strings are illegal in XML
(and XML does not provide a way to escape such characters to make them legal).
When JAXB marshals objects that contain these illegal characters in strings, it
currently includes those characters in the XML, thus generating invalid XML.
Later when it comes time to unmarshal the XML back into objects, an exception
is thrown due to the illegal character. This could spell disaster for a system
that, for example, write objects as XML or fast infoset into a database and then
cannot read them back out later.
JAXB should not be allowed to ever generate invalid XML. If an exception is
going to be thrown, it should be thrown when generating the XML, not when trying
to decode it. So a minimum requirement should be that JAXB throw an exception
when attempting to generate invalid XML, or that it should at least strip out
the characters that would be invalid (or have a property on the marshaller that
allows this to be set).
However, JAXB is also supposed to be converting an object to XML and back
losslessly, so an even better solution would be to do a consistent kind of
escaping of the offending characters in such a way that when the strings are
marshalled back in, the original string can be reconstructed.
It should be straightforward to come up with an escaping scheme that
guarantees lossless translation from Strings to XML and back (e.g., convert 0x1f
to "\u001f" or "JAXB_UNICODE_001f" or something unlikely to appear by
accident). I don't know that it's possible to guarantee that XML generated
through some other process won't ever be accidentally interpreted as containing
"escaped" strings, but it can be made very unlikely.
Below is the simplest unit test I could come up with that exposes the problem.

public void testBinary() throws JAXBException

{ JAXBContext jxbc = JAXBContext.newInstance(OneString.class); OneString orig = new OneString(); orig.setString("\u001f"); ByteArrayOutputStream s = new ByteArrayOutputStream(); Marshaller m = jxbc.createMarshaller(); m.marshal(orig, s); String xml = s.toString(); OneString result = (OneString) jxbc.createUnmarshaller().unmarshal(new ByteArrayInputStream(xml.getBytes())); assertEquals("\u001f", result.getString()); }

@XmlRootElement(name = "oneString")
private static class OneString {
String string;
public String getString()

{ return string; }

public void setString(String s)

{ this.string = s; }

}

There are workarounds for this issue, e.g., at http://tinyurl.com/cq9u58; but as
it currently exists, this is a dangerous bug that can make data unreadable.



 Comments   
Comment by ranboii [ 18/Mar/09 ]

Actually, I meant to post this URL demonstrating a workaround:
http://blog.lesc.se/2009/03/escape-illegal-characters-with-jaxb-xml.html
which at least illustrates I'm not the only one to have seen this issue. Of
course, a fix would be much better than a workaround.

Comment by Pavel Bucek [ 02/Apr/09 ]

partially fixed in trunk.

IllegalArgumentException should be thrown whether you try marshal string with
invalid xml content. But there is a catch. Invalid characters can occur when
UTF-32 is used (it happens because of encoding its characters to UTF-16 which is
java native encoding).

Anyway, it is still far from perfect and needs some additional work.

Adjusting priority and assigning to myself.

Comment by Pavel Bucek [ 02/Apr/09 ]

reassigning

Comment by mnsam [ 11/May/12 ]

As per the workaround, is this the list of unsupported characters ?

"\u0000\u0001\u0002\u0003\u0004\u0005" +
"\u0006\u0007\u0008\u000B\u000C\u000E\u000F\u0010\u0011\u0012" +
"\u0013\u0014\u0015\u0016\u0017\u0018\u0019\u001A\u001B\u001C" +
"\u001D\u001E\u001F\uFFFE\uFFFF"

Comment by aldaranalton [ 13/May/15 ]

What about an option to remove automatically all not printable characters?

str.replaceAll("\\P{Print}", "");




[JAXB-1073] jaxb:globalBindings optionalProperty="primitive" causes NullPointer in xjc Created: 08/May/15  Updated: 11/May/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: vace117 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

Apache Ant(TM) version 1.8.2 compiled on December 3 2011



 Description   
bindings.xml
<?xml version="1.0" encoding="UTF-8"?>
<jaxb:bindings
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" version="2.1">

    <jaxb:globalBindings optionalProperty="primitive" />
</jaxb:bindings>
APPTransactionData.xsd
<?xml version="1.0" encoding="ISO-8859-1"?>
<xs:schema	targetNamespace="http://www.agr.gc.ca/APP"
			xmlns:app="http://www.agr.gc.ca/APP"
			xmlns:xs="http://www.w3.org/2001/XMLSchema">

    
	<xs:complexType name="Shareholder_Type">
		<xs:sequence>
			<xs:element name="Controlling_Member" type="xs:boolean" minOccurs="0" maxOccurs="1"/>
			<xs:element name="Producer_Reference_Id" type="app:Producer_Reference_Id_Type"/>
		</xs:sequence>	
	</xs:complexType>

	<xs:simpleType name="Producer_Reference_Id_Type">
		<xs:restriction base="xs:string" />
	</xs:simpleType>
	

</xs:schema>
build.xml
	<xjc 	destdir="${schema.source.dir}"
			schema="APPTransactionData.xsd"
			binding="bindings.xml"
			package="${schema.generated.package}">

My intent here is to force isControllingMember() method have a primitive boolean return type, as opposed to Boolean.

Running my Ant task causes this exception:

java.lang.NullPointerException
        at com.sun.codemodel.JVar.annotate(JVar.java:188)
        at com.sun.codemodel.TypedAnnotationWriter.create(TypedAnnotationWriter.java:247)
        at com.sun.codemodel.JVar.annotate2(JVar.java:192)
        at com.sun.tools.xjc.generator.bean.field.AbstractField.getXew(AbstractField.java:354)
        at com.sun.tools.xjc.generator.bean.field.AbstractField.writeXmlElementAnnotation(AbstractField.java:286)
        at com.sun.tools.xjc.generator.bean.field.AbstractField.annotateElement(AbstractField.java:242)
        at com.sun.tools.xjc.generator.bean.field.AbstractField.annotate(AbstractField.java:157)
        at com.sun.tools.xjc.generator.bean.field.AbstractFieldWithVar.createField(AbstractFieldWithVar.java:79)
        at com.sun.tools.xjc.generator.bean.field.UnboxedField.<init>(UnboxedField.java:79)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at com.sun.tools.xjc.generator.bean.field.GenericFieldRenderer.generate(GenericFieldRenderer.java:69)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.generateFieldDecl(BeanGenerator.java:777)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.generateClassBody(BeanGenerator.java:558)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:261)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:169)
        at com.sun.tools.xjc.model.Model.generateCode(Model.java:288)
        at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:524)
        at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:457)
        at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:380)
        at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:103)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:390)
        at org.apache.tools.ant.Target.performTasks(Target.java:411)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
        at org.apache.tools.ant.Main.runBuild(Main.java:809)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

If I modify bindings.xml like this:

bindings.xml
<?xml version="1.0" encoding="UTF-8"?>
<jaxb:bindings
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" version="2.1">
    
    <jaxb:globalBindings optionalProperty="primitive" generateIsSetMethod="false" />
</jaxb:bindings>

then my ShareholderType class gets successfully generated. Unfortunately, adding generateIsSetMethod attribute causes optionalProperty="primitive" not to work anymore for the boolean field (now the return type on isControllingMember() is Boolean), so this is not a workaround.



 Comments   
Comment by Iaroslav Savytskyi [ 11/May/15 ]

Thank you for reporting.
I've successfully reproduced the problem.





[JAXB-546] Custom IDResolver gets wrong target type with IDREF collections Created: 02/Sep/08  Updated: 21/Apr/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1.7
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: uryssel Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File Reflect.java    
Issuezilla Id: 546
Tags: 2_2_8

 Description   

The issue is described in the forum:
http://forums.java.net/jive/thread.jspa?threadID=45481&tstart=120

When using IDREFed collections:

@XmlIDREF
Set<Y> ySet;

the resolve() method of a custom IDResolver gets Object.class as targetType,
but it should be Y.class. This results on wrong ID resolving.

If I use an empty derived class instead:

class YSet extends HashSet<Y> {}
...
@XmlIDREF
YSet ySet;

then I get the right targetType in the resolve() method.



 Comments   
Comment by Pavel Bucek [ 04/Mar/09 ]

Would you please provide the schema file and/or reproducible testcase? Thanks in
advance.

Comment by Pavel Bucek [ 06/Mar/09 ]

I agree with Wolfgang - see attached mail:

(workaround available and this is not part of jsr222 -> adjusting priority to P4)

================================================
The reason resolve() is called with Object.class for the target type when
a field of some parameterized type is annotated with @XmlIDREF is
simply because that's the way Java works. At runtime, Set<Foo> is
erased to Set<? extends Object> or Set<?>. See this simple test
program and its output:

mport java.util.*;
import java.lang.reflect.*;
public class Reflect {
public List<String> sList;
public ArrayList<String> sArrayList;
private static void dr( String fname ) throws Exception {
Class reflectClass = Reflect.class;
Field sListField = reflectClass.getField( fname );
System.out.println( sListField.toString() );
Class sListClass = sListField.getType();
System.out.println( sListClass.toString() );
if( sListClass instanceof GenericDeclaration )

{ TypeVariable<?>[] typeVars = sListClass.getTypeParameters(); System.out.println( "generic " + typeVars.length + " parameter" ); Type[] types = typeVars[0].getBounds(); System.out.println( "bounds " + types.length + ": " + types[0].toString() ); System.out.println( "name " + typeVars[0].getName() ); }

}
public static void main( String[] args ) throws Exception

{ dr( "sList" ); dr( "sArrayList" ); }

}
=========================================
public java.util.List Reflect.sList
interface java.util.List
generic 1 parameter
bounds 1: class java.lang.Object
name E
public java.util.ArrayList Reflect.sArrayList
class java.util.ArrayList
generic 1 parameter
bounds 1: class java.lang.Object
name E
==========================================

The code in com/sun/xml/bind/v2/runtime/reflect/Lister.java,
latest release, around line 140 seems to indicate that the
declared parameter type is available, but perhaps I've
not understood it in full.

The ID Resolver is an extension of Sun's implementation.
The official JAXB documentation doesn't contain any hint for
this; as far as I know, Kohsuke's blog is the only place where this
feature is published.

The original reporter has found a reasonable workaround by
declaring a dedicated wrapper type for the parameterized
container class, so that ID resultion into separate namespaces
is applicable for IDREFs in containers as well.

================================================

Comment by Pavel Bucek [ 06/Mar/09 ]

I forgot change priority...

Comment by ktcorby [ 06/Mar/09 ]

I think it would be much more convenient if there was an additional parameter to
the annotation, like @IDRef(targetType=String.class) or possibly an additional
annotation (@IDRefType(String.class)), so that the resolver could map to the
proper type at runtime.

I realize this may not be a possible short-term solution, but I wanted to
mention it.

Comment by larsrc [ 07/Aug/09 ]

Created an attachment (id=322)
Update example source showing the old example plus a part that shows that getGenericType can find the right type.

Comment by larsrc [ 07/Aug/09 ]

Using getGenericType() instead of getType() allows you to find the actual type.
With getType(), you're affected by erasure.

Comment by realsonic3 [ 05/Sep/12 ]

Hello. Can you please tell can this issue be fixed? Thanks.

Comment by Iaroslav Savytskyi [ 11/Sep/12 ]

Hi,realsonic3,

As I see with "getGenericType" is looks optimistic. So we will try to add it to 2.2.7.

Comment by realsonic3 [ 26/Sep/12 ]

Sorry, but in which java version will be JAXB 2.2.7? Thanks a lot.

Comment by Iaroslav Savytskyi [ 26/Sep/12 ]

It's no need to wait for JDK integration. You can use JAXB as standalone application.

Comment by realsonic3 [ 12/Nov/12 ]

Can you please fill "Fix Version/s:" field?

Comment by realsonic3 [ 20/Jun/13 ]

Hello. Can you please update when this issue will be fixed? Thanks.

Comment by Iaroslav Savytskyi [ 21/Jun/13 ]

Hi,

I hope I'll be able to fix it in 2.2.8

Comment by realsonic3 [ 10/Sep/13 ]

Let me please update you. This bug causes a problem that two or more objects with same ID but different types are unmarshalled as one type.

Comment by realsonic3 [ 15/Oct/13 ]

Any chances it will be fixed in 2.2.8?

Comment by Iaroslav Savytskyi [ 16/Oct/13 ]

We are quite busy with maintenance now. So I can't promise.

Comment by realsonic3 [ 21/Apr/15 ]

Hi. Are there any chances to get the issue resolved?..





[JAXB-875] Import schema (via multiple transitive path) causes error of "'XxxType' is already defined", when episode feature comes in play. Created: 03/Jan/12  Updated: 21/Apr/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.4u1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: phantom_john Assignee: Martin Grebac
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File NGCCRuntimeEx.java     Zip Archive schema-episode.2011-12-22_15-57.ComplexImports.zip    
Tags: episode, import, jaxb-xjc, metro2_2-waived, schema

 Description   

I'm using maven-jaxb2-plugin to generate Java classes from schema files, and want to put the schema files into different modules, using its episode feature.

The same set of schema files can be compiled altogether in one shot without issue. But when split them into two modules, the issue surfaces. The <import/> relationship among my schema files is comparatively complex.

The issue turns out to be rooted in the jaxb-xjc (Sun RI), the version I've tested is 2.2.4u1.

Please use the attached maven project to reproduce the issue. It's stemmed from a real project.

I've patched the class NGCCRuntimeEx in jaxb-xjc version 2.2.4u1. That patch is just the starting point of fixing the issue, and it works for me. It may not be the right/ultimate solution though. The basic idea is to enhance the ParserContext to remember what schemas have been imported.



 Comments   
Comment by phantom_john [ 03/Jan/12 ]

Error Stack Trace:

[ERROR] Error while parsing schema(s).Location [ jar:file:/C:/Workbench/Project/References/schema-episode/one/target/schema-episode-one-1.0.0.jar!/META-INF/schema/SC.types.xsd

{14,13}

].
org.xml.sax.SAXParseException: 'SCT' is already defined
at com.sun.xml.xsom.impl.parser.ParserContext$1.reportError(ParserContext.java:180)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.reportError(NGCCRuntimeEx.java:175)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.reportError(NGCCRuntimeEx.java:178)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.checkDoubleDefError(NGCCRuntimeEx.java:150)
at com.sun.xml.xsom.impl.parser.state.Schema.action5(Schema.java:127)
at com.sun.xml.xsom.impl.parser.state.Schema.onChildCompleted(Schema.java:1287)
at com.sun.xml.xsom.impl.parser.state.NGCCHandler.revertToParentFromText(NGCCHandler.java:183)
at com.sun.xml.xsom.impl.parser.state.complexType.text(complexType.java:1634)
at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.processPendingText(NGCCRuntime.java:236)
at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.endElement(NGCCRuntime.java:312)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.util.SubtreeCutter.endElement(SubtreeCutter.java:112)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.endElement(CustomizationContextChecker.java:199)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner$LocationResolver.endElement(DOMForestScanner.java:140)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:255)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:127)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:92)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:100)
at com.sun.tools.xjc.reader.internalizer.DOMForestParser.parse(DOMForestParser.java:104)
at com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:267)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:347)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.importSchema(NGCCRuntimeEx.java:258)
at com.sun.xml.xsom.impl.parser.state.importDecl.action0(importDecl.java:85)
at com.sun.xml.xsom.impl.parser.state.importDecl.leaveElement(importDecl.java:184)
at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.endElement(NGCCRuntime.java:314)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.util.SubtreeCutter.endElement(SubtreeCutter.java:112)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.endElement(CustomizationContextChecker.java:199)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner$LocationResolver.endElement(DOMForestScanner.java:140)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:255)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:127)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:92)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:100)
at com.sun.tools.xjc.reader.internalizer.DOMForestParser.parse(DOMForestParser.java:104)
at com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:267)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:347)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.importSchema(NGCCRuntimeEx.java:258)
at com.sun.xml.xsom.impl.parser.state.importDecl.action0(importDecl.java:85)
at com.sun.xml.xsom.impl.parser.state.importDecl.leaveElement(importDecl.java:184)
at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.endElement(NGCCRuntime.java:314)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.util.SubtreeCutter.endElement(SubtreeCutter.java:112)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.endElement(CustomizationContextChecker.java:199)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner$LocationResolver.endElement(DOMForestScanner.java:140)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:255)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:127)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:92)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:100)
at com.sun.tools.xjc.reader.internalizer.DOMForestParser.parse(DOMForestParser.java:104)
at com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:267)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:347)
at com.sun.xml.xsom.impl.parser.ParserContext.parse(ParserContext.java:128)
at com.sun.xml.xsom.parser.XSOMParser.parse(XSOMParser.java:168)
at com.sun.xml.xsom.parser.XSOMParser.parse(XSOMParser.java:157)
at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:518)
at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:376)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:172)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:118)
at org.jvnet.mjiip.v_2_2.XJC22Mojo.loadModel(XJC22Mojo.java:45)
at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:35)
at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:22)
at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:282)
at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:147)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Comment by Niels Bertram [ 01/May/14 ]

Any chance someone can comment on "Applying" the patch? I have used the attached NGCCRuntimeEx.java sources and patched the xsom version 20130531 library. Then I rebuild JAXB-RI 2.2.7 (also tried 2.2.10-SNAPSHOT) and ran the provided test case. Does not seem to make any difference to fixing the problem described. This is a really anoying bug that pretty much renders JAXB inoperable for multi-episode compilation. If anyone has pointer this would be much appreciated.

Comment by maciej.bajolek [ 26/May/14 ]

I'm getting similar exception when I try to use MOXY provider to marshal dynamically XML to JSON.
The application loads multiple .xsd's that define in different targetNamespaces. The intention is to be able to use dynamic binding without a need of generating jaxb POJO classes using commandline xjc compiler nor maven-jaxb2 plugin.

From some reasons I cannot attach source code.

Comment by Niels Bertram [ 27/May/14 ]

I got the originally posted path to work with XSOM, JAXB 2.2.7 and also the 2.2.10-SAPSHOT. I documented the steps needed to apply it on GitHub. Maybe that helps anyone that runs into this problem.

Comment by Niels Bertram [ 17/Jan/15 ]

Hi Martin,

any chance we can coordinate a proper fix for this significant issue with the team that writes the xsom library? JAXB 2.2.11 is out and I find myself having to patch every new version, which really sucks. What does it take to fix this?

Kind Regards,
Niels

Comment by Michael Osipov [ 30/Jan/15 ]

Interesting to say that I have a similiar usecase with JAXB and the Maven JAXB2 Plugin which does work but the very same setup with wsimport leads to this error. Since there is no activity from Oracle, I presume either Oracle has abandoned this project or expect suffering users to pay $$$ for the fix.

Comment by Iaroslav Savytskyi [ 03/Feb/15 ]

No, no The project isn't abandoned.
Let me check what can I do with this.

Comment by Michael Osipov [ 03/Feb/15 ]

Can't wait to test a fix. That would probably solve a serious wsimport bug.

Comment by Niels Bertram [ 16/Apr/15 ]

Looks like JAXB is truly abandoned. The problem is within XSOM and that library is baked into the JAXB RI build process last time I checked. The original fix proposed by phantom_john fixes the issue. Will anyone care if I submit a pull request for XSOM and JAXB-RI to incorporate the patch documented at https://github.com/bertramn/xsom-patch ?

Comment by Michael Osipov [ 21/Apr/15 ]

Niels Bertram, this is so annoying. I'd like to test your patch but I am really sick of maintaining a fork of every single component Oracle is not capable/ or unwilling to fix. Let me have a look at it later that week and I will come back to you.

Comment by Niels Bertram [ 21/Apr/15 ]

Agreed, especially if there is no real workaround and the patching is not really trivial given one has to first patch the xsom library and then also stuff around in about 35 locations in the JAXB-RI pom model to get this thing to shade the patched xsom code in. I did see that the JAXB-RI maven build is slowly getting "uncoupled" under the glassfish banner. Maybe some day we would just be able to maven exclude the defective xsom library from jaxb-xjc and add a fixed one to the dependencies section. This ticket is slowly becoming a larger issue for us in building component based JAXB binding modules so maybe we collectively need to raise Oracle Support tickets.





[JAXB-1011] Base complex type "AdditionalParametersBaseType" is derived by restriction, while this complex type "AdditionalParametersType" is derived by extension. OGC WCS 2.0.0 - Created: 07/Apr/14  Updated: 06/Apr/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: aquaglia Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64bit
Java 6



 Description   

Trying to generate the bindings for
http://schemas.opengis.net/wcs/2.0/wcsAll.xsd

E:\schemas\inspire\wcs\wcs-2_0_1\wcs\2.0.1>"E:\quaglan\software\jaxb-ri-2.2.7\ja
xb-ri-2.2.7\bin\xjc" wcsAll.xsd -d "E:\quaglan\projects\subversion\sdi\Geoportal
\Common\MavenProjects\INSPIREGeoportalBindings\src\main\java" -target 2.1 -b bin
dings.xjb -extension -catalog catalog.xml
parsing a schema...
[ERROR] Base complex type "AdditionalParametersBaseType" is derived by restricti
on, while this complex type "AdditionalParametersType" is derived by extension.
This is not currently handled by XJC, but we are seeking input on this issue. Pl
ease report this to the JAXB team.
line 54 of http://schemas.opengis.net/ows/2.0/owsAdditionalParameters.xsd

Failed to parse a schema.



 Comments   
Comment by jbaldo [ 26/Aug/14 ]

H
Is there any activity on this issue?

Comment by tastle [ 06/Apr/15 ]

Hit the same thing recently. This is going to be a problem with anything based on OWS 2.0 from the OGC.





[JAXB-1072] Package level annotations don't work for inner classes Created: 20/Mar/15  Updated: 20/Mar/15

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tuomas_kiviaho Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

com.sun.tools.internal.jxc.ap.InlineAnnotationReaderImpl#getPackageAnnotation assumes that TypeElement#getEnclosingElement() returns always PackageElement but with inner classes the eclosing element will be a TypeElement.

As a fix I propose that Element#getKind() is inquired instead for ElementKind.CLASS|INTERFACE(|ENUM?) and TypeElement#getEnclosingElement() is repeated until ElementKind.PACKAGE is reached.

@Override
public <A extends Annotation> A getPackageAnnotation(Class<A> a, TypeElement clazz, Locatable srcPos) {
    Element enclosingElement = clazz;
    do {
        enclosingElement = enclosingElement.getEnclosingElement();
    } while (enclosingElement instanceof TypeElement);
    return LocatableAnnotation.create(enclosingElement.getAnnotation(a), srcPos);
}





[JAXB-1070] Bad pom dependencies lead to java.lang.NoClassDefFoundError: com/sun/xml/bind/api/ErrorListener Created: 09/Mar/15  Updated: 13/Mar/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: chengas123 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Running jaxb-xjc bombs out because there's no dependency declared on jaxb-core

More info here:
https://github.com/jacobono/gradle-jaxb-plugin/issues/15



 Comments   
Comment by Iaroslav Savytskyi [ 10/Mar/15 ]

It's not clear where is the problem.

From poms I see that:
org.glassfish.jaxb:jaxb-xjc has dependency on org.glassfish.jaxb:jaxb-core
com.sun.xml.bind:jaxb-xjc depends on org.glassfish.jaxb:jaxb-xjc

Comment by chengas123 [ 10/Mar/15 ]

Iaroslav, there's no dependency on com.sun.xml.bind:jaxb-core though.

Also, com.sun.xml.bind:jaxb-xjc only optionally depends on org.glassfish.jaxb:jaxb-xjc, so it's not going to pull it in. I don't think it should even have an optional dependency though. An optional dependency is typically used if com.sun.xml.bind:jaxb-xjc had code referencing classes from org.glassfish.jaxb:jaxb-xjc because you wanted to provide some extra features for it or something, but didn't want to force everyone to pull that jar into their project since only some people would use it. However, in this case, there seems to be no reference at all to any classes in that jar even for optional functionality, so it'd be better to just remove that dependency entirely.

Most build systems can show the dependency graph. E.g. if you use gradle you can run "gradle dependencies"

Here's the dependency graph with 2.2.7:

runtime - Runtime classpath for source set 'main'.
--- com.sun.xml.bind:jaxb-xjc:2.2.7
--- com.sun.xml.bind:jaxb-core:2.2.7
+--- javax.xml.bind:jaxb-api:2.2.7
--- com.sun.istack:istack-commons-runtime:2.16

Here's the dependency graph with 2.2.11:

runtime - Runtime classpath for source set 'main'.
--- com.sun.xml.bind:jaxb-xjc:2.2.11

Comment by Iaroslav Savytskyi [ 13/Mar/15 ]

In the version 2.2.8 we fixed JAXB maven project. Because of this new groupId: org.glassfish.jaxb was introduced.
https://jaxb.java.net/nonav/2.2.11/docs/ch02.html#a-2-2-8

The old one 'com.sun.xml.bind' shouldn't be used. It exists only for building legacy jaxb-ri.zip bundle.

Here is current dependency tree for JAXB runtime:

[INFO] — maven-dependency-plugin:2.8:tree (default-cli) @ jaxb-runtime —
[INFO] org.glassfish.jaxb:jaxb-runtime:jar:2.2.12-SNAPSHOT
[INFO] +- org.glassfish.jaxb:jaxb-core:jar:2.2.12-SNAPSHOT:compile
[INFO] | +- javax.xml.bind:jaxb-api:jar:2.2.13-b150205.1422:compile
[INFO] | +- org.glassfish.jaxb:txw2:jar:2.2.12-SNAPSHOT:compile
[INFO] | - com.sun.istack:istack-commons-runtime:jar:2.21:compile
[INFO] +- org.jvnet.staxex:stax-ex:jar:1.7.7:compile
[INFO] +- com.sun.xml.fastinfoset:FastInfoset:jar:1.2.13:compile
[INFO] - junit:junit:jar:4.11:test
[INFO] - org.hamcrest:hamcrest-core:jar:1.3:test





[JAXB-172] More Schema Annotations/Documentation to Javadoc Created: 06/Jun/06  Updated: 12/Mar/15

Status: Reopened
Project: jaxb
Component/s: xjc
Affects Version/s: 2.0 FCS
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: vorburger Assignee: Martin Grebac
Resolution: Unresolved Votes: 39
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://jaxb.dev.java.net/servlets/ReadMsg?list=users&msgNo=5469


Attachments: XML File test.xsd    
Issue Links:
Duplicate
is duplicated by JAXB-839 More Schema Annotations/Documentation... Resolved
Issuezilla Id: 172

 Description   

As discussed on the "Schema Annotations/Documentation to Javadoc" thread on
users@jaxb.dev.java.net (see
https://jaxb.dev.java.net/servlets/ReadMsg?list=users&msgNo=5469) :

>> If you find cases where it doesn't work as you expected,
>
> . not the same complexType's sequence/element* documentation (which
> I'd think you'd expect on the respective getters/setters, instead of
> that pretty useless "Gets the value of the ... property."), nor a
> simpleType's annotation/documentation that turns into a @XmlEnum
> public enum, where one would expect both JavaDoc of the class as well
> as the individual enum values, from the
> simpleType/restriction/enumeration/annotation/documentation.
> (Additionally maybe putting schema/annotation/documentation into
> package-info.java as JavaDoc; although not sure how to deal with one
> namespace schema in several .xsd... not sure how that looks in XSOM by
> the time you process this?)

Please let me know if you need more details, schemas or code - hoping above is
clear.

When you do commit code for this, I'd would be happy to try a nightly build and
provide feedback; please add a comment to this Bugzilla and we'll give the next
build a shot. Thanks!



 Comments   
Comment by kohsuke [ 16/Jun/06 ]

Created an attachment (id=105)
Schema I used to test the problem.

Comment by vorburger [ 21/Jul/06 ]

FYI: http://jira.codehaus.org/browse/XFIRE-507

Comment by kohsuke [ 24/Sep/07 ]

Also in this category is javadoc for enumeration values.

Comment by kohsuke [ 06/Feb/08 ]
      • Issue 431 has been marked as a duplicate of this issue. ***
Comment by kohsuke [ 06/Feb/08 ]

issue #431 that was marked as a duplicate for this had 25 votes on its own, so
this appears to be a highly requested feature.

Comment by Aleksander Adamowski [ 22/Oct/09 ]

CCing myself (Bugzilla doesn't allow without a comment).

Comment by dkulp [ 22/Oct/09 ]

This is also the blocker for a CXF issue:

https://issues.apache.org/jira/browse/CXF-2486

Comment by skells [ 26/Oct/09 ]

I have a plugin that adds documentation to the getters, setters and the fields,
that works withthe placement that xmlspy used for the documentation. I would
not say that it is complete, but it works OK for the cases that we use.

Theer are some problems with it mostly related to the API the generate the
javadoc, and I would not say that the code is clean ....

I can share the code if anyone is interested in taking it forward

Comment by dkulp [ 26/Oct/09 ]

If you'd like to donate the code to CXF, we could certainly use it. CXF
already has a couple plugins to workaround XJC issues.

Just log a JIRA at:
https://issues.apache.org/jira/browse/CXF
and attach the code.

Comment by dkulp [ 11/Feb/10 ]

skells,

In CXF, we've recently setup a subproject to house additional XJC plugins
that the community finds useful. We'd love to have your contribution if the
offer still stands.

Comment by kpsdevi [ 11/May/11 ]

The schema is provided by the service provider and they have defined integer enumeration values with documentation but without names as given below.
<xsd:simpleType name="XYZCodeSimpleType">
<xsd:annotation>
<xsd:documentation>A data type for an enumeration of XYZ Codes.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="0">
<xsd:annotation>
<xsd:documentation>Undefined</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="1">
<xsd:annotation>
<xsd:documentation>Left</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="2">
<xsd:annotation>
<xsd:documentation>Right</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>

1) JAXB 2 has not generated classes for those enum types. So I added global bindings as given below

<jaxb:globalBindings typesafeEnumMemberName="generateName">

Then I was able to generate classes as given below with prefix "VALUE_" in the name, which was confusing as my enum values start with 0.

public enum XYZCodeSimpleType {

/**

  • Undefined
  • */
    @XmlEnumValue("0")
    VALUE_1("0"),

/**

  • Left
  • */
    @XmlEnumValue("1")
    VALUE_2("1"),

/**

  • Right
  • */
    @XmlEnumValue("2")
    VALUE_3("2");

2) So I have used external bindings to define name as given below.

<jaxb:bindings node="//xsd:simpleType[@name='XYZSimpleType']">
<jaxb:typesafeEnumClass>
<jaxb:typesafeEnumMember value="0" name="UNDEFINED" />
<jaxb:typesafeEnumMember value="1" name="LEFT" />
<jaxb:typesafeEnumMember value="2" name="RIGHT" />
</jaxb:typesafeEnumClass>
</jaxb:bindings>

With this external binding I was able to generate classes with names as given below but I lost the documentation which is there in the schema. Because of that I need to duplicate documentation as well in jaxb bindings which I don't want to.

public enum XYZCodeSimpleType {

@XmlEnumValue("0")
UNDEFINED("0"),
@XmlEnumValue("1")
LEFT("1"),
@XmlEnumValue("2")
RIGHT("2");

3) I looked at JAXB 2.2.3 source code and figured out the cause of this issue. Issue is in the method "buildCEnumConstants" of "com.sun.tools.xjc.reader.xmlschema.SimpleTypeBuilder". The documentation from schema is getting overwritten even when the javadoc is not specified in the bindings and getting nullified if there is no value in the bindings.

if( mem!=null )

{ name = mem.name; mdoc = mem.javadoc; }

So the above code should be modified as given below

if( mem!=null ) {
name = mem.name;
if (mem.javadoc!=null)

{ //Fix mdoc = mem.javadoc; }

}

I request you to fix this issue and release the update of JAXB2.2.3 as soon as possible.

Comment by Martin Grebac [ 30/May/11 ]

Unfortunately have to close this one as incomplete because the original thread wast lost and I'm not able to grasp the roots of the bug here. Recently I fixed one javadoc issue with enums thanks to a specific submission, but other than that I think I need more info on what is requested here. Feel free to reopen if you have that. Thanks.

Comment by os111 [ 31/May/11 ]

Not sure why this was closed?

As I understood it the original intent was to include documentations from the XSD in the Javadoc of autogenerated code.

For example the following from schema snippet

<attribute name="documentedAttribute" type="string" use="optional">
<annotation>
<documentation>This attribute can be either 1, 2, or 3.</documentation>
</annotation>
</attribute>

Generates the following javadoc:

/**

  • Gets the value of the documentedAttribute property.
  • @return
  • possible object is
  • {@link String }
  • */

The javadoc should also include the schema's documentation.

Comment by vorburger [ 01/Jun/11 ]

JAXB-839 (new) created to avoid this being swiped under the carpet.

Comment by Martin Grebac [ 01/Jun/11 ]

Understood, thanks for the clarifications here.

Comment by marcelstoer [ 20/Oct/13 ]

Just found here thanks to a really helpful SO answer.

Comment by kwakeroni [ 12/Mar/15 ]

Just wanted to indicate that the reverse might also be useful: include javadocs as annotation/documentation in the generated xsd.





[JAXB-1071] Support Plugin Customizations on All Schema Components Created: 11/Mar/15  Updated: 11/Mar/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: flutter Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JavaSE 1.7


Tags: customizations, plugin, xjc

 Description   

Currently, Plugin Customizations applied to a schema component that doesn't support a vendor Customization (like e.g. modelGroupDecl or attGroupDecl) will lead to an error message in XJC, since there is no way for the plugin to "markAsAcknowledged()" the plugin customization instance before it is consumed by the BGMBuilder's UnusedCustomizationChecker.
In the case of "group" or "attributeGroup" an additional complication is that these declarations are only processed in the context of the complexType that uses them rather than individually.

Improvement suggestion:

  • Handle "group" and "attributeGroup" declarations as first-class model elements instead of only through their usage.
  • Make all model elements based on schema components that support the "xs:annotation" element implement "Customizable", and hand any customization found down to the plugins for acknowledgement.





[JAXB-1069] prefix-mapping is not predictable Created: 06/Mar/15  Updated: 10/Mar/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mihxil Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If you generate XML which includes other XML's, you might have a different default namespace in two different javax.xml.bind.annotation.XmlNs in package-info.

In the current implementation of com.sun.xml.bind.v2.runtime.JAXBContextImpl it is not predictable which of the two will win. Actually in java 7 I get other ones that in java 8.

I propose to change

                        xmlNsSet = new HashSet<XmlNs>();

in

                        xmlNsSet = new LinkedHashSet<XmlNs>();

(at line 327)

I think this will fix it. The set will be at insertion order, and we will not end up with 'ns3' for our current default namespace...



 Comments   
Comment by Iaroslav Savytskyi [ 10/Mar/15 ]

Can you please provide simple testcase to cover this issue?
Thanks.





[JAXB-1068] Remove mentions of RELAXNG from the documentation and the CLI help until it somehow works Created: 26/Feb/15  Updated: 26/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The xjc /? output prints the following out:

  -relaxng           :  treat input as RELAX NG (experimental,unsupported)
  -relaxng-compact   :  treat input as RELAX NG compact syntax (experimental,unsupported)

This is formulated similar to:

  -dtd               :  treat input as XML DTD (experimental,unsupported)
  -wsdl              :  treat input as WSDL and compile schemas inside it (experimental,unsupported)

As DTD and WSDL compilation do (more or less) work, I assumed, RELAXNG can be also works somehow.

This assumption costed be today 0.5 PT. I have tried to compile a minimal RELAXNG_COMPACT example and consequently encountered JAXB-1065, JAXB-1066 (which I worked around), and, finally JAXB-1067.

With these issue I can with confidence say that RELAXNG_COMPACT compilation simply does not work. This is different from just "unsupported" (which I would interpret as "we don't officially support this") or "experimental" (which I would interpret as "we haven't thoroughly tested it yet"). It just does not work, completely and probably for a long time already.

Therefore I would consider these command line options and the documentation to be misleading:

  -relaxng           :  treat input as RELAX NG (experimental,unsupported)
  -relaxng-compact   :  treat input as RELAX NG compact syntax (experimental,unsupported)

It costed me today a few hundred euros worth of time invested.

Please remove the command line options and correct the documentation in order not to mislead further users.

Thank you.






[JAXB-1067] XJC with RELAXNG_COMPACT generates classes without properties Created: 26/Feb/15  Updated: 26/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File georss.rnc    

 Description   

After workarounds for [jaxb-1065] and [jaxb-1066] I have managed to generated the classes. To my surprize, classes are empty:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "")
@XmlRootElement(name = "featureName")
public class FeatureName {


}





[JAXB-1066] XJC fails on RELAXNG_COMPACT with NPE Created: 26/Feb/15  Updated: 26/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

NPE:

java.lang.NullPointerException
	at com.sun.tools.xjc.reader.Ring.get(Ring.java:97)
	at com.sun.tools.xjc.model.CPropertyInfo.<init>(CPropertyInfo.java:124)
	at com.sun.tools.xjc.model.CElementPropertyInfo.<init>(CElementPropertyInfo.java:103)
	at com.sun.tools.xjc.reader.relaxng.ContentModelBinder.onRepeated(ContentModelBinder.java:114)
	at com.sun.tools.xjc.reader.relaxng.ContentModelBinder.onZeroOrMore(ContentModelBinder.java:103)
	at com.sun.tools.xjc.reader.relaxng.ContentModelBinder.onZeroOrMore(ContentModelBinder.java:70)
	at org.kohsuke.rngom.digested.DZeroOrMorePattern.accept(DZeroOrMorePattern.java:32)
	at org.kohsuke.rngom.digested.DPatternWalker.onContainer(DPatternWalker.java:42)
	at org.kohsuke.rngom.digested.DPatternWalker.onGroup(DPatternWalker.java:63)
	at org.kohsuke.rngom.digested.DPatternWalker.onGroup(DPatternWalker.java:27)
	at org.kohsuke.rngom.digested.DGroupPattern.accept(DGroupPattern.java:35)
	at com.sun.tools.xjc.reader.relaxng.RELAXNGCompiler.bindContentModel(RELAXNGCompiler.java:165)
	at com.sun.tools.xjc.reader.relaxng.RELAXNGCompiler.compile(RELAXNGCompiler.java:158)
	at com.sun.tools.xjc.reader.relaxng.RELAXNGCompiler.build(RELAXNGCompiler.java:123)
	at com.sun.tools.xjc.ModelLoader.loadRELAXNG(ModelLoader.java:607)
	at com.sun.tools.xjc.ModelLoader.loadRELAXNGCompact(ModelLoader.java:595)
	at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:166)
	at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:119)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.loadModel(XJC22Mojo.java:50)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:40)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:1)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:488)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:311)
	at org.jvnet.jaxb2.maven2.test.RunXJC2Mojo.testExecute(RunXJC2Mojo.java:30)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

This is due to the Ring not being initialized correctly.

The com.sun.tools.xjc.reader.relaxng.RELAXNGCompiler.build(DPattern, JCodeModel, Options) method should begin a ring and add model to it:


public static Model build(DPattern grammar, JCodeModel codeModel, Options opts )

{ RELAXNGCompiler compiler = new RELAXNGCompiler(grammar, codeModel, opts); // ... Ring.begin(); Ring.add(compiler.model); // ... compiler.compile(); // ... Ring.end(); // ... return compiler.model; }




[JAXB-1065] XJC fails on RELAXNG_COMPACT compilation with datatype library "http://www.w3.org/2001/XMLSchema-datatypes" not recognized Created: 26/Feb/15  Updated: 26/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File georss.rnc    

 Description   

When trying to compile the attached (or any) RNC file I get:

datatype library "http://www.w3.org/2001/XMLSchema-datatypes" not recognized

Possibly related to JAXB-128 and JAXB-465.

I believe a link to the datatype library is somehow broken.



 Comments   
Comment by lexi [ 26/Feb/15 ]

Java 1.5 workaround is obviously not an option.

Comment by lexi [ 26/Feb/15 ]

Tested with 2.2.11 via maven-jaxb2-plugin and 2.2.4-2 via command-line.

Comment by lexi [ 26/Feb/15 ]

Stack trace (unfortunately not too enlightning):

org.xml.sax.SAXParseException; systemId: file:/C:/Projects/workspaces/mj2p/maven-jaxb2-plugin-project/tests/rnc/src/main/resources/georss.rnc; lineNumber: 25; columnNumber: 45; datatype library "http://www.w3.org/2001/XMLSchema-datatypes" not recognized
	at org.kohsuke.rngom.binary.SchemaBuilderImpl.error(SchemaBuilderImpl.java:751)
	at org.kohsuke.rngom.binary.SchemaBuilderImpl.makeDataPatternBuilder(SchemaBuilderImpl.java:379)
	at org.kohsuke.rngom.parse.host.SchemaBuilderHost.makeDataPatternBuilder(SchemaBuilderHost.java:150)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.DataExpr(CompactSyntax.java:1856)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.PrimaryExpr(CompactSyntax.java:947)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.AnnotatedPrimaryExpr(CompactSyntax.java:891)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.UnaryExpr(CompactSyntax.java:1079)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Expr(CompactSyntax.java:996)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.ListExpr(CompactSyntax.java:1475)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.PrimaryExpr(CompactSyntax.java:929)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.AnnotatedPrimaryExpr(CompactSyntax.java:891)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.UnaryExpr(CompactSyntax.java:1079)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Expr(CompactSyntax.java:996)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.ElementExpr(CompactSyntax.java:1137)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.PrimaryExpr(CompactSyntax.java:917)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.AnnotatedPrimaryExpr(CompactSyntax.java:891)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.UnaryExpr(CompactSyntax.java:1079)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Expr(CompactSyntax.java:996)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Define(CompactSyntax.java:1618)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Definition(CompactSyntax.java:1590)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.GrammarComponent(CompactSyntax.java:1561)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.GrammarBody(CompactSyntax.java:1547)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.TopLevelGrammar(CompactSyntax.java:747)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Input(CompactSyntax.java:442)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.parse(CompactSyntax.java:135)
	at org.kohsuke.rngom.parse.compact.CompactParseable.parse(CompactParseable.java:55)
	at com.sun.tools.xjc.ModelLoader.loadRELAXNG(ModelLoader.java:606)
	at com.sun.tools.xjc.ModelLoader.loadRELAXNGCompact(ModelLoader.java:595)
	at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:166)
	at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:119)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.loadModel(XJC22Mojo.java:50)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:40)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:28)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:488)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:311)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Comment by lexi [ 26/Feb/15 ]

This is most probably due to com.sun.msv.datatype.xsd.ngimpl.DataTypeLibraryImpl missing from the classpath.

Comment by lexi [ 26/Feb/15 ]

Ok, so how it seems, for RelaxNG to work on these schemas, it needs a datatype library for XML Schema.
This was a part of xsdlib or msv in the past and in modern days could only be found in com.sun.xml.bind:jaxb-extra-osgi.
Which exists in 2.2.11 version. But is somehow labelled for OSGi and is not under the new groupId.

Adding com.sun.xml.bind:jaxb-extra-osgi to the classpath solves this particular problem. The compilation still fails but for other reasons.

What is not clear to me is what is happening here. Why does RelaxNG Datatype library only appear in jaxb-extra-osgi? What does it have to do with OSGI at all? Why isn't it in the new group id? what are the plans here? I have a not so good feeling about this.





[JAXB-1022] '>' not escaped in doclet comments Created: 14/May/14  Updated: 18/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: schrepfler Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven, xjc

 Description   

When generating the JAXB classes using XJC, the javadoc example xml instance has the '<' properly encoded while the closing '>' is not.
The result is that if one is making a maven release which triggers the javadoc compilation the errors will break that step thus the whole release.
This was observed on MacOSX and JDK8.



 Comments   
Comment by Lukas Jungmann [ 14/May/14 ]

I'd say this is jdk8 related, duplicate of https://java.net/jira/browse/JAXB-973 and not a blocker, since workaround is to pass -Xdoclint:none to javadoc executable as is documented ie here: http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html

Comment by p.gillissen [ 18/Feb/15 ]

hi schrepfler
I had the same issue (with Java 7) and solved it by updating the Maven JAXB plugin (org.jvnet.jaxb2.maven2:maven-jaxb2-plugin) to version 0.12.3. Now all my > are correctly escaped.





[JAXB-1064] The setters generated for the array fields cause NPE if the passed in array was null Created: 16/Jan/15  Updated: 13/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mystarrocks Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: xjc
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags: jaxb, jaxb-xjc, xjc

 Description   
    public void setNames(String[] values) {
      int len = values.length;
      this.names = ((String[]) new String[len] );
      for (int i = 0; (i<len); i ++) {
          this.names[i] = values[i];
      }
    }

Here's how XJC generates a setter if a collectionType of indexed was specified in the JAXB binding file. This throws an NPE if the values attribute was null. Especially for non-mandatory elements, this can very easily cause an NPE.

What's the reason for doing so? Does the JAXB spec require it this way? If not, perhaps changing the way the method is generated to include an appropriate null check can help avoid this? Maybe if it the passed in parameter was null, an empty array can be assigned to the field in question?

I looked at the JAXB spec and there is a mention for indexed fields that the argument should be discarded if it was null:

Page 58 of JAXB 2.2 spec

• setId(Type [])
The array setter method defines the property’s set value. If the
argument itself is null then the property’s set value, if any, is discarded.
If the argument is not null and....

I think this behavior can be observed in all the versions of jaxb-xjc, but the one my CXF client uses is 2.2.10 the CXF codegen plugin version being 3.0.2.

I'm OK with creating a pull request to get this fixed, if that's fine.



 Comments   
Comment by mystarrocks [ 01/Feb/15 ]

Any updates on this one? As it stands, the collectionType="indexed" is simply unusable.

Comment by Iaroslav Savytskyi [ 02/Feb/15 ]

I have to check. Now it looks like we are violating 2 rulers: getter returns empty array for null value and setter doesn't accept null argument. So array value couldn't be reset.

Even more. What we have to return in case if value is null and we are asked about it's length???

Comment by mystarrocks [ 03/Feb/15 ]

I don't think there's a need to change the getters or the length operations in any way. The getters should return the value as is, i.e null if null or the array if it was set previously using the setter; while the length should either return the length of the array or throw an NPE depending on if it was set previously or not.

The only requirement here is to comply with the spec for the setters for array fields by not setting explicitly if a null was passed as an argument.

Like:

    public void setNames(String[] values) {
      if (values == null) return; // simply ignore a null argument
      int len = values.length;
      this.names = ((String[]) new String[len] );
      for (int i = 0; (i<len); i ++) {
          this.names[i] = values[i];
      }
    }
Comment by Iaroslav Savytskyi [ 03/Feb/15 ]

I've reread specification more carefully (JAXB 2.2, section 5.5.2.1):

For getter: null should be returned instead of empty array in case if value wasn't set. Now user has no chance to determine if array was set without editing source class generated by XJC.

For setter: "If the argument itself is null then the property’s set value, if any, is discarded." -> previous value set to null.

Comment by mystarrocks [ 03/Feb/15 ]

I'm not quite sure about this statement:

Now user has no chance to determine if array was set without editing source class generated by XJC.

What's the rationale here? Why would the user want to know if the property was set or not? The user would merely call the getter to access the field whose value should be returned as:

  • null if it was not set previously or
  • the array if it was set previously.

Besides, the field will be null if it wasn't set anyway - b/c we don't initialize it with an array be default, do we?

Sorry if I'm missing something obvious, but I'm not understanding why this change to the setter will affect anything to the other invariants on the field. Can you please elaborate?

Comment by Iaroslav Savytskyi [ 03/Feb/15 ]

In my opinion, your proposition

if (values == null) return; // simply ignore a null argument

for setter, is against the specification. It's explicitly written that null argument for setter should reset already set value. So couldn't be ignored.

Comment by mystarrocks [ 03/Feb/15 ]

You're right,

if (values == null) return; // simply ignore a null argument

deviates from the spec. How about:

    public void setNames(String[] values) {
      if (values == null) {
          this.names = null; // discard the previously set value on the field per spec by setting the field to be null
          return;
      }
      int len = values.length;
      this.names = ((String[]) new String[len] );
      for (int i = 0; (i<len); i ++) {
          this.names[i] = values[i];
      }
    }

This complies with the spec by discarding the previously set value if the argument was null and do the usual thing otherwise. What the clients really expect here is null safety, so whatever variant of the above code that can offer that should be good.

Comment by Iaroslav Savytskyi [ 05/Feb/15 ]

Thanks for reporting. Will be fixed.





[JAXB-913] XmlAdapter<String, Boolean> should be able to apply to small-b boolean (primitive) bean fields as well as Boolean fields Created: 26/Jul/12  Updated: 16/Jan/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: daveboden Assignee: Martin Grebac
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Registering an XmlAdapter<String, Boolean> with the Unmarshaller and marking the bean field with an @XmlJavaTypeAdapter annotation results in the error message:

...is not applicable to the field type boolean.

Here's someone else with a similar request:
http://stackoverflow.com/questions/6552740/jaxb-suppress-boolean-attribute-if-false

My use case is that although I'm happy for marshalling to convert a boolean to the string "true" or "false" for output in XML, I'd like more flexibility in the unmarshalling. Ideally "true" and "TRUE" would unmarshal successfully to boolean = true.
I'm using Jaxb for a simple unmarshalling task of XML to a bean and am not providing a schema or a binding customisation file. For the record, even for the big-B Boolean case it would be great to be able to register default behaviour for booleans without having to tag the bean field with @XmlJavaTypeAdapter. There seems to be no facility to programatically override this default behaviour at the Unmarshaller level.

I could choose to transform the TRUE into a true as part of a preprocessing step. However, I only want to apply that preprocessing logic when the value is definitely going to be attached to a boolean or Boolean. Because I don't have a schema, any preprocessor would have to change all instances of "TRUE", even if they are destined to be a String and would be far better staying as "TRUE".



 Comments   
Comment by javaprog [ 16/Jan/15 ]

Another user with the same issue: http://stackoverflow.com/questions/14053063/marshaling-a-long-primitive-type-using-jaxb

Also affects version 2.2.7.





[JAXB-1063] Add option to SchemaGen not to dump intermediary bytecode in output directory Created: 15/Jan/15  Updated: 15/Jan/15

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: lennartj Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Abstract

The SchemaGenerator generates bytecode from which it creates XSDs. However, it also has the option to generate XSDs from annotated Java source code. We need a nifty option to place these (intermediary, generated) bytecode files in another directory than the generated XSDs. I would suggest

-bytecodeDirectory path or perhaps -bd path analogous to the current -d path for where generated XSDs are located. If the -bytecodeDirectory path option is not given, the intermediary bytecode files should be generated in the same locations as it is today.

Example

A short example might illustrate the reason here.

  1. Given a Maven project with an annotated Java class - say src/main/java/some/package/Foo.java - we want to use schemagen to generate an XSD.
  2. Both the compiled bytecode of the class above, and the generated XSD should go into the resulting JAR.
  3. Using some plugin, we instruct schemagen to generate the XSD from the annotated Java source file. The resulting command is something like {{schemagen -d target/generated-resources -episode target/generated-resources/META-INF/sun-jaxb.episode src/main/java/some/package/Foo.java }}

The effect of the schemagen operation above is that the scema1.xsd and the META-INF/sun-jaxb.episode files are added to the Maven build as resources - and therefore correctly copied into the resulting JAR.

However ... in the same directory resides a schemagen-compiled intermediary bytecode file some/package/Foo.class. This file should not be copied into the resulting JAR. In fact, it might be a problem that it even exists, since the actual compilation step by the maven-compiler-plugin or plain javac compiler may have a different suite of arguments than schemagen.

Consequence: required, complex cleanup operation

I now have to perform a complex and unnecessary cleanup, which I would like not to have do to:

  1. Figure out which files below the target/generated-resources/ directory are actually bytecode which originated from the schemagen compilation
  2. Remove only those bytecode files from the target/generated-resources/ directory but preserve the generated XSDs and episode files.

A better solution

The complex cleanup operation need not be done at all if schemagen could be fired with something like

schemagen -d target/generated-resources -episode target/generated-resources/META-INF/sun-jaxb.episode -bytecodeDirectory target/schemagen_work src/main/java/some/package/Foo.java

This would imply that I would stash the generated intermediary bytecode files in another directory than the target/generated-resources ... and hence no cleanup operation would be required.






[JAXB-986] Using marshaller on xjc generated classes causes Exception. Works in jdk7, not in jdk 8. Created: 24/Oct/13  Updated: 09/Jan/15

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: rne11 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b109)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b51, mixed mode)


Tags: jaxb-xjc

 Description   

Using marshaller on xjc generated classes causes java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String

Works in jdk7, not in jdk 8.

Java file generated by xjc in jdk8 is different than what is produced
by xjc in jdk7.

Schema:
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="intlist">
<xs:list itemType="xs:int"/>
</xs:simpleType>
<xs:complexType name="Person">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="scores" type="intlist"/>
</xs:sequence>
</xs:complexType>
<xs:element name="person" type="Person"/>
</xs:schema>

Difference in Person.java
in jdk8:
@XmlList
@XmlElement(type = Integer.class)
@XmlSchemaType(name = "anySimpleType")
protected List<Integer> scores;

in jdk 7:
@XmlList
@XmlElement(type = Integer.class)
protected List<Integer> scores;

REGRESSION : Additional Information
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b109)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b51, mixed mode)

xjc 2.2.8-b20130806.1801

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile xsd to Java files:
$ xjc.exe -p jaxb -d src test.xsd

Compile test program and run.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected an XML file to be created with Person object.
ACTUAL -
Exception

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.String

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package jaxb;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBElement;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;
import java.io.File;
import java.io.FileOutputStream;
import java.util.List;

public class App {

public static void main( String[] args ) throws Exception {

File file = new File( "test-out.xml");
FileOutputStream fis = new FileOutputStream( file );
ObjectFactory of = new ObjectFactory();

Person person = of.createPerson();
person.setName( "Bob" );
List<Integer> values = person.getScores();
values.add( 1 );
values.add( 2 );

JAXBElement jaxbElement = of.createPerson( person );

JAXBContext ctx = JAXBContext.newInstance( "jaxb" );
try

{ Marshaller marshaller = ctx.createMarshaller(); // Dies here with: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String marshaller.marshal( jaxbElement, fis ); fis.close(); }

catch( JAXBException e )

{ throw new RuntimeException( e ); }

}
}



 Comments   
Comment by dkulp [ 12/Sep/14 ]

This should be raised from Minor to Critical.

This bug also exists in "JAXB RI v2.2.10-b140310.1920".

This is preventing the WS-Discovery service in CXF from working properly as the WS-Discovery API's have a XmlList of QNames and trying to marshal the Discovery messages is causing ClassCast exceptions from QName to String.

Comment by jotel71 [ 09/Jan/15 ]

It's obvious regression and priority should be much higher then minor!

The problem is when some of the elements references an extended simple type by name. The XJC adds @XmlSchemaType annotation to the generated classes which won't match actual type used. And having such classes is not possible to properly marshal it to the XML stream without class cast exception!

Bug still exists in version 2.2.11

Comment by jotel71 [ 09/Jan/15 ]

As a workaround (not nice but working) you can use annotate plugin and override wrongly produced annotation. Just add a similar constriction to your bindings:

 <jaxb:bindings node="//xs:element[@type='YourSimpleType']">
        <annox:annotate target="field">@javax.xml.bind.annotation.XmlSchemaType(name="YourSimpleType")</annox:annotate>
</jaxb:bindings>
Comment by dkulp [ 09/Jan/15 ]

As another workaround, the CXF team created an xjc plugin that tried to detect this problem and removes the XmlSchemaType annotation:

http://repo1.maven.org/maven2/org/apache/cxf/xjcplugins/cxf-xjc-bug986/3.0.3/

I still cannot believe a bug this critical and has a reproducible test case has been open for more than a year.





[JAXB-1062] Behavior changed while setting collection property Created: 08/Jan/15  Updated: 08/Jan/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: roekoe Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When updating from 2.2.5 to 2.2.7 we noticed a small change in how collections (at least lists in our case) get initialized. Previously the setter received a fully initialized list. As of 2.2.7 the setter receives a semi initialized , which receives some or all (timing?) of its content after the property gets called.

I'll attach an simple code example when upgrading the pom jaxb-impl version from 2.2.6 to 2.2.7 the testcase fails.



 Comments   
Comment by roekoe [ 08/Jan/15 ]
import java.io.StringReader;
import java.io.StringWriter;
import java.io.Writer;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import javax.xml.bind.JAXB;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;

import org.junit.Test;

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.core.IsCollectionContaining.hasItems;
import static org.hamcrest.core.StringContains.containsString;


public class ClassWithCollectionPropertyTest {

    @Test
    public void testToXml() throws Exception {
        Root root = new Root();
        root.setList(Arrays.asList("hello", "world"));
        Writer writer = new StringWriter();
        JAXB.marshal(root, writer);

        assertThat(writer.toString(), containsString("<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n" +
            "<root>\n" +
            "    <list>hello</list>\n" +
            "    <list>world</list>\n" +
            "</root>"));
    }

    @Test
    public void testFromXml() throws Exception {
        String input = "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n" +
            "<root>\n" +
            "    <list>hello</list>\n" +
            "    <list>world</list>\n" +
            "</root>";

        Root result = JAXB.unmarshal(new StringReader(input), Root.class);
        assertThat(result.getList(), hasItems("hello", "world"));
    }

    @XmlAccessorType(XmlAccessType.PROPERTY)
    public static class Root {

        private List<String> internal = new ArrayList<String>();

        public List<String> getList() {
            ArrayList<String> answer = new ArrayList<String>();
            answer.addAll(internal);
            return answer;
        }

        public void setList(List<String> list) {
            this.internal.addAll(list);
        }
    }
}
Comment by roekoe [ 08/Jan/15 ]
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>boeskol</groupId>
  <artifactId>jaxb</artifactId>
  <version>1.0-SNAPSHOT</version>

  <dependencies>
    <dependency>
      <groupId>com.sun.xml.bind</groupId>
      <artifactId>jaxb-impl</artifactId>
      <!--<version>2.2.6</version>-->
      <version>2.2.7</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>




[JAXB-273] Java annotations to generate xsd documentation/appinfo elms Created: 01/Nov/06  Updated: 06/Jan/15

Status: Open
Project: jaxb
Component/s: spec
Affects Version/s: 2.1 EA1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: wiebe_ruiter Assignee: Unassigned
Resolution: Unresolved Votes: 20
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Duplicate
is duplicated by JAXB-369 Add ability to inject javadoc into sc... Resolved
Issuezilla Id: 273

 Description   

Annotation(s) ( class level, member level ) to have documentation/appinfo
elements generated by schemagen.

E.g. when annotating a class with @XsdAppinfo:

@XsdAppInfo( value="blah" )

The xsd should have a complex type definition:

...
<xs:element name="bar" nillable="true">
<xs:complexType>
<xs:annotation>
<xs:appinfo>blah</xs:appinfo>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ns1:foo">

...

In this example a simple String is used, but optionally xml elements may be
necessary. Probably a user should be able to define a custom ( inherited ? )
annotation to generate xml elements instead of a simple string.



 Comments   
Comment by Dennis Kieselhorst [ 21/Oct/10 ]

The opposite is in issue JAXB-460.

Comment by lisa_winkler [ 13/Jun/12 ]

Can anyone comment on the likelihood of this feature being added? It seems like it would be of widespread benefit.

Comment by lennartj [ 25/Dec/14 ]

If I understand things correctly, SchemaGen does not support copying JavaDoc for classes and methods into XSD documentation annotations. I would consider this a flaw in schemagen, as the generated XSD lacks some potentially important information as found within the JavaDoc of a class or method.

Should we try to file a bug against the tooling of the JDK itself? (It would certainly be more optimal if schemagen was augmented to handle documentation as well). Or would the more pragmatic approach be to fix this in a post-process step of the JAXB plugin (ANT or Maven) instead of having to wait for the schemagen tool to be patched? The functionality is certainly needed.

Basically, I would expect

/**
 * Some information here...
 */
@XmlType(namespace = "http://www.jguru.se/foobar")
@XmlAccessorType(XmlAccessType.FIELD)
public class SomeType { ... }

To have the following generated

<xs:complexType name="someType">
     <xs:annotation>
          <xs:documentation>
               Some information here...
          </xs:documentation>
     </xs:annotation>
     <xs:complexContent> 
     ...
Comment by laune [ 25/Dec/14 ]

Transferring javadoc text into a schemagen generated XSD file is going to be quite difficult as schemagen processes class files, which don't contain javadoc text.

Assuming this minor difficulty can be overcome, the javadoc text isn't very readable when dumped between a pair of XML tags. Apart from the HTML tags, there are inline tags (@link, @see,...) that need interpretation to be useful.

Since a field with getter and setter may contain three sets of javadoc: should they all be combined into a single annotation?

And when all of this has been resolved: how would that wealth of annotation be presented to the user?

Comment by lennartj [ 25/Dec/14 ]

Schemagen processes bytecode - that is indeed true. But we need the JavaDoc information in the XSD world as well; parts of the beauty of an XML binding framework is that it can be used to transfer the information from the Java realm into the XML realm and back.

Loosing some information in the process is problematic, partly because the remaining bits may not be as intuitive in terms of clarity or usability and partly because we need both java code and javadoc documentation to provide clear guidance about how a class or method should be used or what data it carries. Moreover, I would really suggest we avoid introducing yet another set of annotations to clutter the code even more. Instead, I feel it is good enough to work with what we have - namely JavaDoc comments. This is particularly true if our goal is to enable developers to generate *professional quality* XSDs from annotated Java code using JAXB wrapping SchemaGen and JavaDoc working in concert with one another.

I believe this implies two things:

  1. Generating XSD's is (at least) a 2 step process, where we use schemagen and javadoc to generate separate documents which are merged to the final, resulting XSD.
  2. While JavaDoc is the standard tool of choice to convert javadoc comments to HTML, we need a custom JAXB doclet to generate XSD annotations from javadoc comments. For example, we need to use JAXB annotations to find the normative javadoc - in case a class is annotated with @XmlAccessorType(XmlAccessType.FIELD), the javadoc for a property should be read from the field and vice versa.

WRT how to process inline tags, we could either use another processing tool such as Doxia or simply use our own doclet implementation to harvest that information - the purpose should be to enable developers not to loose *all* JavaDoc documentation when generating XSDs. I am certain that the conversion will improve over time.

Comment by Dennis Kieselhorst [ 29/Dec/14 ]

I like the idea of transferring javadoc into the XSD without new annotations. In my view having documentation is better than no documentation.

JAXB-460 should be easier, however it's open for years now.

Comment by lennartj [ 06/Jan/15 ]

Hm... http://docs.oracle.com/javase/8/docs/technotes/tools/unix/schemagen.html claims that SchemaGen works either on .java files or .class files. Is this a change from earlier on?

Anyhow ... I got a working example on how to inject supplied JavaDoc as XML annotations into generated XSDs. While it does require access to Java Sources, one could possibly extract JavaDoc data from existing JavaDoc (thus not requiring that actual .java files be present).





[JAXB-1061] The primitive char type is not correctly handled in the isSet method Created: 19/Dec/14  Updated: 19/Dec/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File schema.xsd    

 Description   

When generating code for the following char property, XJC generates incorrect isSetChar method. Schema fragment:

	<xs:complexType name="complexTypeWithChar">
		<xs:sequence>
			<xs:element name="char">
				<xs:annotation>
					<xs:appinfo>
						<jaxb:property>
							<jaxb:baseType name="char" />
						</jaxb:property>
					</xs:appinfo>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="xs:string">
						<xs:minLength value="1"/>
						<xs:maxLength value="1"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
		</xs:sequence>
	</xs:complexType>

Generates:

    @XmlElement(name = "char", type = String.class)
    protected char _char;

    public boolean isSetChar() {
        return (this._char!= null);
    }

Which does not compile.

Apparently, char is somehow not considered to be primitive.

I have attached a sample schema to reproduce this.



 Comments   
Comment by lexi [ 19/Dec/14 ]

I think the problem is here:

https://github.com/gf-metro/jaxb/blob/dae7d777e6d65728a08f840cc1aef4454f4f542f/jaxb-ri/xjc/src/main/java/com/sun/tools/xjc/model/CBuiltinLeafInfo.java#L310-L347

No builtin type for `char`. Mapped as `unsignedShort` here:

https://github.com/gf-metro/jaxb/blob/3461152ffe39baf32b8550d47d18d58cdbc139c5/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java#L266-L275





[JAXB-1058] NPE because of the DummyListField.$get Created: 13/Dec/14  Updated: 15/Dec/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Today I've spent a few hours hunting an NPE bug.

I was trying to add the generateMixedExtensions="true" feature to a working project and started getting an NPE:

Caused by: java.lang.NullPointerException
	at com.sun.codemodel.JInvocation.generate(JInvocation.java:176)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:363)
	at com.sun.codemodel.JInvocation.generate(JInvocation.java:185)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JAssignment.generate(JAssignment.java:65)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JAssignment.state(JAssignment.java:69)
	at com.sun.codemodel.JFormatter.s(JFormatter.java:386)
	at com.sun.codemodel.JBlock.generateBody(JBlock.java:448)
	at com.sun.codemodel.JBlock.generate(JBlock.java:436)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JBlock.state(JBlock.java:464)
	at com.sun.codemodel.JFormatter.s(JFormatter.java:386)
	at com.sun.codemodel.JBlock.generateBody(JBlock.java:448)
	at com.sun.codemodel.JBlock.generate(JBlock.java:436)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JBlock.state(JBlock.java:464)
	at com.sun.codemodel.JFormatter.s(JFormatter.java:386)
	at com.sun.codemodel.JMethod.declare(JMethod.java:464)
	at com.sun.codemodel.JFormatter.d(JFormatter.java:376)
	at com.sun.codemodel.JDefinedClass.declareBody(JDefinedClass.java:832)
	at com.sun.codemodel.JDefinedClass.declare(JDefinedClass.java:803)
	at com.sun.codemodel.JFormatter.d(JFormatter.java:376)
	at com.sun.codemodel.JFormatter.write(JFormatter.java:406)
	at com.sun.codemodel.JPackage.build(JPackage.java:442)
	at com.sun.codemodel.JCodeModel.build(JCodeModel.java:311)
	at com.sun.codemodel.JCodeModel.build(JCodeModel.java:301)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.writeCode(XJC22Mojo.java:98)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:42)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:28)

After some debugging I've found out that the NPE was thrown because the passed JMethod was null.

And that was because of the DummyListField.$get - a getter for the dummy list field. $get is a private field which is never initialized in the code, but used in the field accessor, for instance:

        public void toRawValue(JBlock block, JVar $var) {
            // [RESULT]
            // $<var>.addAll(bean.getLIST());
            // list.toArray( array );
            block.assign($var,JExpr._new(codeModel.ref(ArrayList.class).narrow(exposedType.boxify())).arg(
                $target.invoke($get)
            ));
        }

This leads to $target.invoke(...) with null and consequently to the NPE during code generation.

I think it was forgotten to initialize the $get field. Other list fields have something like:

        $get = writer.declareMethod(listT,"get"+prop.getName(true));
        writer.javadoc().append(prop.javadoc);
        JBlock block = $get.body();
        fixNullRef(block);  // avoid using an internal getter
        block._return(acc.ref(true));

I think this appeared here because the generateMixedExtensions="true" feature probably creates a dummy field. Should it be dummy, actually? Anyway, somehow with that feature a DummyListField is created and it has a bug.



 Comments   
Comment by lexi [ 15/Dec/14 ]

I've made a temporal fix in form of a plugin:

https://github.com/highsource/jaxb2-basics/blob/master/basic/src/main/java/org/jvnet/jaxb2_commons/plugin/fixjaxb1058/FixJAXB1058Plugin.java





[JAXB-1059] MixedExtendedComplexTypeBuilder should creates a property with a lowercase name Created: 14/Dec/14  Updated: 14/Dec/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The {{}} creates the dummy property as follows:

p = prop.createDummyExtendedMixedReferenceProperty("contentOverrideFor" + ct.getName(), ct, ts);

(Around line 99.)

This makes both "private" as well as "public" property names lowercase and results in getter names like:

public List<Object> getcontentOverrideForGenericMetaDataType() { ... }

Which is not correct.

Please correct it to:

p = prop.createDummyExtendedMixedReferenceProperty("ContentOverrideFor" + ct.getName(), ct, ts);





[JAXB-335] wsimport usage of xjc episode files Created: 19/Mar/07  Updated: 24/Nov/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1.2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mshaffer55 Assignee: Martin Grebac
Resolution: Unresolved Votes: 16
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 335

 Description   

I have five schemas that are used in common by multiple services, so I ran them
through xjc -episode together to produce a single episode file containing
bindings for all of them, thinking that I could feed this to all of the
wsimports. But not all five schemas are used by all the services, and I am
getting errors like this out of wsimport, when it encounters bindings for
schemas that don't happen to be used by the service:

[ERROR] SCD "x-schema::tns" didnt match any schema component

So if I want to compile the schemas only once, I must compile them one at a
time, and then use only the specific episode files needed in each wsimport? OK,
but that's going to get cumbersome fast as the schema population grows. It would
be nice to be able to have episode files that could contain bindings for
arbitrary schemas, and xjc/wsimport just used the parts it needs.



 Comments   
Comment by E.Wiles [ 24/Sep/14 ]

Excuse me, but has there been any solution to this issue? I'm in the same boat with multiple XSD files, and having the same issue.

Comment by Michael Osipov [ 24/Sep/14 ]

E.Wiles, I am suffering too. No avail from Oracle. I have found a crappy workaround which does its job but I am not happy with.

Comment by E.Wiles [ 24/Sep/14 ]

I found one too:

1) Change each

<bindings scd="x-schema::tns"

to:

<bindings if-exists='' scd="x-schema::tns"

2) Delete each

<schemaBindings map="false">...</schemaBindings>

block, entirely.

The first tells wsimport to not worry if the schema isn't being used by that particular wsdl.
The second change keeps wsimport from deciding that there are no mappings at all for that package.

Comment by flutter [ 24/Nov/14 ]

This issue still seems to exist in JAXB 2.2 included in JRE 1.7.0_71





[JAXB-514] passing episode file to xjc api creates incorrect Model Created: 11/Jun/08  Updated: 24/Nov/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1.7
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: ramapulavarthi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 22
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive jaxb_episode.zip     Text File jaxb_episode.zip     Text File jaxb_episode.zip    
Issuezilla Id: 514

 Description   

Attached is the testcase which simulates the way wsimport invokes xjc.
Passing episode works when directly used with xjc ant task. But wsimport uses
xjc api.
This is required for https://jax-ws.dev.java.net/issues/show_bug.cgi?id=368



 Comments   
Comment by ramapulavarthi [ 11/Jun/08 ]

Created an attachment (id=254)
testcase

Comment by ramapulavarthi [ 11/Jun/08 ]

Created an attachment (id=255)
Updated testcase

Comment by ramapulavarthi [ 08/Jan/09 ]

Another bug is filed on jax-ws
(https://jax-ws.dev.java.net/issues/show_bug.cgi?id=690) on the same note.

Comment by Pavel Bucek [ 16/Jan/09 ]

I've tried xjc with episodes from command line and via com.sun.tools.xjc.api.XJC
and both ways are working fine.

My code:

SchemaCompiler sc = XJC.createSchemaCompiler();

InputSource file = new
InputSource("/Users/pavel/jaxb/bugs/514/tryout2/b.xsd");
InputSource episode = new
InputSource("/Users/pavel/jaxb/bugs/514/tryout2/a.episode");

sc.parseSchema(file);
sc.getOptions().addBindFile(episode);
// sc.getOptions().scanEpisodeFile(new
File("/Users/pavel/jaxb/bugs/514/tryout2/a.jar")); // works too

S2JJAXBModel model = sc.bind();

JCodeModel jcm = model.generateCode(null, null);
jcm.build(sc.getOptions().createCodeWriter());

It is working even with xsd and episode you've provided with testcase (after
fixed typos in file wrap.xsd (complesElement and AbstrcatType).

In uploaded testase you're checking for Hello class but it's already present in
episode file so xjc won't generate it. I'm not sure if I understood this
correctly so please reply if I'm missing something.

Comment by Pavel Bucek [ 04/Mar/09 ]

marking as incomplete

Comment by Pavel Bucek [ 19/Mar/09 ]

Closing as invalid. Feel free to reopen with additional info.

Comment by ramapulavarthi [ 20/Mar/09 ]

Reopening the issue.
Please see the testcase. As in the testcase, JAX-WS tries to get Element Mapping
from the model. Although the model has proper schema information,
model.get(QName) is not returning anything. I think there is some problem in
populating the JAXBModelImpl.byXmlName map.

Also, please use the newly attached testcase to reproduce the issue.

Comment by ramapulavarthi [ 20/Mar/09 ]

Created an attachment (id=301)
New testcase with the reopened issue.

Comment by Pavel Bucek [ 24/Mar/09 ]

Can you provide file common-targets.xml, please?

– removing incomplete keyword

– ant output:
$ ant
Buildfile: build.xml
/Users/pavel/jaxb/config/common-targets.xml could not be found

BUILD FAILED
java.io.FileNotFoundException: /Users/pavel/jaxb/config/common-targets.xml (No
such file or directory)

– build.xml:
$ cat ./build.xml | grep common-targets
<!ENTITY commonTargets SYSTEM "../../../../config/common-targets.xml">

Comment by ramapulavarthi [ 24/Mar/09 ]

The common-targets does not have much other than setting up the classpath for
xjc and defining xjc task.

Your earlier test case should suffice for reproducing the problem, just check
the model (model.get(QName)), if it can give info about the elements defined in
hello.xsd

Comment by fribeiro [ 14/Apr/09 ]

Any update yet?

Comment by Pavel Bucek [ 16/Apr/09 ]

We have a workaround.

After short brainstorming session with snajper we've discovered that the easiest
way to support this is do two models - one with episode file included and one
without it (so first will be used to generate java classes and second for
mapping check).

We are aware of performance loss in this case but this isn't used in runtime so
it shouldn't be a major issue.

Please, let us know if this is acceptable (at least for now).

Comment by euxx [ 12/May/09 ]

Is there an update on this?

This issue is very critical for us, we have a common schema and number of
extensions that should reuse the same binding files. So, without this fix the
wsimport can produce a conflicting code that fails at the runtime. Thanks.

Comment by fribeiro [ 08/Sep/09 ]

Any update yet?

Comment by Martin Grebac [ 11/Sep/09 ]

Pavle, did you contact Rama/Jitu about this one?

Comment by Martin Grebac [ 17/Sep/09 ]

Adding an evaluation here such that I don't forget again. Also setting target
milestone.

The reason why JAXB standalone testcase works and why wsimport fails is the very
basic definition of episode files - JAXB ignores types specified in episode
files in it's processing. It doesn't have enough info to create a model from
them. However, wsimport is requesting this information - it requests Mapping
instance from model.get(QName) call. That includes Type and Annotation info.

One possibility to fix this would be to make a place in episode files to provide
such info. Better solution I think is this:

When wsimport requests information for a qname which is not found in the model,
jaxb would look up the episode file, find a corresponding classname; it will
load the class from classpath, read the annotation/type info using reflection
and return it back to jax-ws in mapping instance.

There's a risk in this however: we don't know yet what other information jax-ws
would require from the model, so this fix could be just a beginning and could
uncover more hidden issues. I'll check with Jitu/Rama about what info is
required in the model. Pavel will look into this for 2.2 release.

Comment by Martin Grebac [ 27/Oct/09 ]

This is not really a bug in JAXB, it's an enhancement, so updating the issue. We'll target this one for 2.2.1
as it requires larger changes than we expected. We made several enhancements, but it requires more work
since JAX-WS requires a lot more information to be present from the classes.

Comment by fribeiro [ 02/Nov/09 ]

Thanks for the update.

Comment by fribeiro [ 25/Jan/10 ]

Any update yet?

Comment by fribeiro [ 04/Oct/10 ]

Any update yet?

Comment by marcelcasado [ 24/Nov/11 ]

Any update ? Which version will be this available? Is there a work around? Thanks

Comment by cedric.vidal [ 08/Jun/12 ]

I'm also interested for an update on this.

Comment by RyanCarpenter [ 06/Mar/13 ]

I also appear to be running into this issue and would appreciate an update, if one is available. Thanks

Comment by Iaroslav Savytskyi [ 07/Mar/13 ]

Hi,

To be honest now we have quite a lot of BUGs to be closed. But the light became visible in the end of the tunnel. So I hope I'll be able to start working with this in 1-2 months.

Iaroslav

Comment by rcardillo [ 19/Jul/13 ]

Some people (myself included) have been waiting years for this. Any update on where this is going? I mean, we cannot really use episode files with wsimport effectively without this fix.

Can you at least provide a list of known workarounds that should be considered? I've been finding it difficult to workaround because in a project that uses episode files to make XML binding libraries, it's also really easy to get something generated that fails at runtime (e.g., multiple ObjectFactories that support the same element cause JAXBContext issues at runtime).

Comment by Michael Osipov [ 25/Feb/14 ]

Any update on this? I wasted an entire day to figure out that this is actually a bug!

Comment by jahutton [ 14/Mar/14 ]

Any update? without this fixed it kind of makes jaxws generation useless.

Comment by Michael Osipov [ 14/Mar/14 ]

I second jahutton's statement. Without decoupling the model from the SEI, it is impossible to support separation of concerns. Iaroslav Savytskyi, an entire year has passed without any progress. Please act!

Comment by bdrx [ 10/Nov/14 ]

Is this issue actually 'IN PROGRESS' meaning is someone actively working on this? Is there an estimated/target release for this? Is there any jaxb/xjc development happening period? What would one need to do to contribute to this project and/or get this moving?

Comment by Michael Osipov [ 10/Nov/14 ]

The status is just in pretense only. Nothing has changed for month.





[JAXB-829] schemagen and xjc should add 'if-exists' to bindings when generating an episode file Created: 13/Apr/11  Updated: 10/Nov/14

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.2.3u1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: matunos Assignee: Martin Grebac
Resolution: Unresolved Votes: 20
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When schemagen or xjc generates an episode file (via the -episode command-line argument; or in the case of the schemagen ant task, the episode attribute), the resultant file should set the 'if-exists' attribute on the 2nd-level bindings element.

Rationale: When generating an episode file, you may be generating bindings for multiple namespaces at once (especially if you're using schemagen and adding the episode file to your META-INF section of a jar file). If you then try to consume that bindings file via xjc (as documented at http://weblogs.java.net/blog/2006/09/05/separate-compilation-jaxb-ri-21), it will fail if your input schema doesn't have references to all of the namespaces included in the episode file. At least, it will fail if you're using the Ant xjc task, I haven't tried from the command line.

However, if the bindings had 'if-exists' set on them, the xjc task would simply keep going (the code that checks for this attribute is in SCDBasedBindingSet::Target::apply).

Concise example:

Output is currently generated like this:

<bindings version="2.1" xmlns="http://java.sun.com/xml/ns/jaxb">
<bindings scd="x-schema::tns" xmlns:tns="http://example.com/SomeSampleNamespace/">
<schemaBindings map="false"/>
<bindings scd="tns:SampleElement">
<class ref="com.example.sample.SampleElement"/>
</bindings>
/.../
</bindings>
</bindings>

If it was instead this (note the if-exists on the bindings with scd attribute):

<bindings version="2.1" xmlns="http://java.sun.com/xml/ns/jaxb">
<bindings scd="x-schema::tns" xmlns:tns="http://example.com/SomeSampleNamespace/" if-exists="">
<schemaBindings map="false"/>
<bindings scd="tns:SampleElement">
<class ref="com.example.sample.SampleElement"/>
</bindings>
/.../
</bindings>
</bindings>

Then the xjc task would ignore any unused bindings when processing it with the -b or from a jar file's META-INF. I think this would be the desired action when using bindings generated as an episode file.



 Comments   
Comment by famod [ 27/Jul/11 ]

I too stumbled upon this issue.

We have multiple xsd-files with individual namespaces that are used by multiple wsdl files that also have individual namespaces. Each wsdl is using only a subset of the xsd files.
In that scenario I tried using the generated episode file for wsdl2java (via maven) and failed because of this issue.

I ended up creating my own bindings-file with if-exists in place.

Btw: Finding "if-exists" in the code (SCDBasedBindingSet) was the last resort for me. I did not find this feature in the Jaxb documentation.

Comment by cpalm [ 27/Feb/13 ]

+1 for this.
Without the if-exists attribute episodes are pretty much useless for most non-trivial use cases.

Comment by bdrx [ 10/Nov/14 ]

Any progress on this feature?





[JAXB-1056] Generation of JAXBElement for Nillable and minOccurs="0" within XMLEmentRef Created: 17/Oct/14  Updated: 17/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lynchie Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using the schema

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://xml.jaxb.test/test"
targetNamespace="http://xml.jaxb.test/test"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">

<xsd:element name="Parent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="NillOne" type="xsd:int" minOccurs="0" nillable="true"/>
<xsd:element ref="NillTwo" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="NillTwo" type="xsd:int" nillable="true"/>
</xsd:schema>

Running this xsd through xjc in 2.2.7 still generates XmlElement Refs with both nillable="true" and minOccurs="0" as a plain Integer and not a JAXBElement<Integer>

//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.2.7 
// See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
// Any modifications to this file will be lost upon recompilation of the source schema. 
// Generated on: 2014.09.10 at 12:30:20 PM BST 
//


package test.jaxb.xml.test;

import javax.xml.bind.JAXBElement;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlElementRef;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;


/**
 * <p>Java class for anonymous complex type.
 * 
 * <p>The following schema fragment specifies the expected content contained within this class.
 * 
 * <pre>
 * &lt;complexType>
 *   &lt;complexContent>
 *     &lt;restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
 *       &lt;sequence>
 *         &lt;element name="NillOne" type="{http://www.w3.org/2001/XMLSchema}int" minOccurs="0"/>
 *         &lt;element ref="{http://xml.jaxb.test/test}NillTwo" minOccurs="0"/>
 *       &lt;/sequence>
 *     &lt;/restriction>
 *   &lt;/complexContent>
 * &lt;/complexType>
 * </pre>
 * 
 * 
 */
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "nillOne",
    "nillTwo"
})
@XmlRootElement(name = "Parent")
public class Parent {

    @XmlElementRef(name = "NillOne", namespace = "http://xml.jaxb.test/test", type = JAXBElement.class, required = false)
    protected JAXBElement<Integer> nillOne;
    @XmlElement(name = "NillTwo", nillable = true)
    protected Integer nillTwo;

    /**
     * Gets the value of the nillOne property.
     * 
     * @return
     *     possible object is
     *     {@link JAXBElement }{@code <}{@link Integer }{@code >}
     *     
     */
    public JAXBElement<Integer> getNillOne() {
        return nillOne;
    }

    /**
     * Sets the value of the nillOne property.
     * 
     * @param value
     *     allowed object is
     *     {@link JAXBElement }{@code <}{@link Integer }{@code >}
     *     
     */
    public void setNillOne(JAXBElement<Integer> value) {
        this.nillOne = value;
    }

    /**
     * Gets the value of the nillTwo property.
     * 
     * @return
     *     possible object is
     *     {@link Integer }
     *     
     */
    public Integer getNillTwo() {
        return nillTwo;
    }

    /**
     * Sets the value of the nillTwo property.
     * 
     * @param value
     *     allowed object is
     *     {@link Integer }
     *     
     */
    public void setNillTwo(Integer value) {
        this.nillTwo = value;
    }

}

This was related to JAXB-840 but it was supposed to be fixed but It appears to still occur

From looking at the code, there is a check in RawTypeSetBuilder$XmlTypeRef.canBeType() that does the following:

            // nillable and optional at the same time. needs an element wrapper to distinguish those
            // two states. But this is not a hard requirement.
            if(decl.isNillable() && parent.mul.isOptional())
                return RawTypeSet.Mode.CAN_BE_TYPEREF;

However, as the NillTwo is a ref inside the xsd, it is parsed using RawTypeSetBuilder$CElementInfoRef.canBeType() which doesn't have a similar check. If I add the code snippet above before the if(target.hasClass()) call it generates the correct java like below:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "nillOne",
    "nillTwo"
})
@XmlRootElement(name = "Parent")
public class Parent {

    @XmlElementRef(name = "NillOne", namespace = "http://xml.jaxb.test/test", type = JAXBElement.class, required = false)
    protected JAXBElement<Integer> nillOne;
    @XmlElementRef(name = "NillTwo", namespace = "http://xml.jaxb.test/test", type = JAXBElement.class, required = false)
    protected JAXBElement<Integer> nillTwo;






[JAXB-1055] Code creating ClassLoader for ant tasks not working properly Created: 15/Oct/14  Updated: 16/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: miroslav.kos Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The implementation in com.sun.tools.xjc.ClassLoaderBuilder#createProtectiveClassLoader#createProtectiveClassLoader() seems not to work properly. It should load always the latest API version (without need to use endorsed mechanism), but it probably worked well only for jdk6.

            // what does this really find for jdk >= jdk7 ?
            URL apiUrl = cl.getResource("javax/xml/bind/JAXBPermission.class"); 
            if(apiUrl==null)
                throw new ClassNotFoundException("There's no JAXB 2.2 API in the classpath");

            cl = new URLClassLoader(new URL[]{ParallelWorldClassLoader.toJarUrl(apiUrl)},cl);

It has to be verified that it adds jaxb-api.jar, not rt.jar for jdk7+.



 Comments   
Comment by Iaroslav Savytskyi [ 15/Oct/14 ]

Hi Miran,

Do you have jaxb-api.jar within endorsed folder? I think it should be there.

Comment by miroslav.kos [ 16/Oct/14 ]

Well, my understanding is that this code is trying to load proper API version without using endorsed mechanism. If you use endorsed, you don't need this classloaders magic stuff.





[JAXB-1053] Use Java 7 diamond operator Created: 04/Oct/14  Updated: 15/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.4u2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: donvip Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK7u67



 Description   

Using xjc bundled in latest JDK7 (7u67 right now), the generated code does not use Java 7 diamond operator.
This results in many warnings in Eclipse, see for example these discussions on StackOverflow:
http://stackoverflow.com/q/22314669/2257172
http://stackoverflow.com/q/19917257/2257172

We should be able to generate code that uses diamond operator, even by default or with a new command line option.



 Comments   
Comment by Iaroslav Savytskyi [ 09/Oct/14 ]

I agree.. This could be nice enhancement. But it have to be postponed until we have to support JDK6.





[JAXB-1044] Catalog is not used to resolve the schema URL provided as an argument to XJC Created: 28/Sep/14  Updated: 07/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive a.zip    

 Description   

I am compiling schemas from public schema repositories, available online.

However, I don't want builds to download these schemas in first place, instead I want them to work with local copies, "redirected" by catalogs.

I have found out that catalogs seem to be not applied to the URL arguments directly passed to XJC.

Please see the attached test case:

xjc a.xsd

works of course.

However assume I want to compile http://www.ab.org/a.xsd directly. This is a legal use case.
But I don't want a.xsd to be downloaded from http://www.ab.org. So I provide a catalog:

REWRITE_SYSTEM "http://www.ab.org" "."

But this catalog does not seem to be applied to the URL I provide as a command-line argument. This fails:

xjc http://www.ab.org/a.xsd -catalog catalog.cat

Fails is a sense that XJC still tries to download a.xsd from http://www.ab.org.

At the same time, if http://www.ab.org/a.xsd would have been included in another schema, this would have worked.



 Comments   
Comment by Iaroslav Savytskyi [ 07/Oct/14 ]

Hi Aleksei,

To be honest, it's clear what are you trying to do, but does it makes sense?

Why will somebody call xjc with

xjc http://www.ab.org/a.xsd -catalog catalog.cat

if he already has a.xsd on his local?

Comment by lexi [ 07/Oct/14 ]

It does make sense. Please also see JAXB-1046, it explains the issue in detail.

Assume we have http://www.ab.org/a.xsd which imports b.xsd relatively. And b.xsd imports a.xsd via an absolute URL: http://www.ab.org/a.xsd.

Which schemas will be compiled if we just compile the local copy of a.xsd? The answer is:

So this is one of the reasons people get "MyType is already defined" (see JAXB-1045). You basically get the same schema (i.e. the same local copy) included via two different systemIds. An that's the problem.

This is not just theory. I work with W3C, OGC, and OASIS schemas and they do this all the time. Some schemas import other schemas relatively, some via absolute URLs. An I have spent days trying to compile these schemas, fighting "MyType is already defined" and "my.xsd is not part of this compilation" errors all the way.

Finally I came to the conclusion that I should not mix compiling local copies and absolute URLs with catalogs. I should compile EVERYTHING uniformely. And since absolute URLs are in play, this should be absolute URLs with catalogs.

I have actually already implemented the workaround for JAXB-1044 in the maven-jaxb2-plugin. It now resolves URLs before passing to XJC. Any you know what? It works just splendid. Take a look at this project:

https://github.com/highsource/w3c-schemas

This works way better than anything I've managed to get working in the past. Actually, the combination of JAXB-1044, JAXB-1045 and JAXB-1046 actually forced me to patch local copies of schemas so that they always use relative URLs. It just did not work the other way round.

If you're still in doubt if this makes sense, try to compile this schema from local copies without patching it:

http://schemas.opengis.net/gml/3.1.1/base/gmlBase.xsd

You will run exactly in the problem I describe above. GML uses SMIL schemas, importing them via absolute URLs. SMIL Schemas, however, import each other via relative URLs. Kaboom.

As I said, I've implemented a workaround in the maven-jaxb2-plugin, but I still would like to get it fixed in the core XJC because I have a few projects which use the command-line XJC and I really won't like to start dancing aroud command-line tools as well.





[JAXB-942] Catalog with PUBLIC definition fails when using an episode Created: 21/Jan/13  Updated: 06/Oct/14

Status: In Progress
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This issue is a result of analysis for MAVEN_JAXB2_PLUGIN-53.

The problem is that using a catalog with PUBLIC definition fails when episode is used as well.

I have a schema b.xsd which imports a schema a.xsd:

<xsd:import namespace="http://maven-jaxb2-plugin/samples/episode/a" schemaLocation="a.xsd"/>

The schema a.xsd is, however placed in a/a.xsd. This can be handled with the following catalog entry:

PUBLIC "http://maven-jaxb2-plugin/samples/episode/a" "a/a.xsd"

This works fine:

xjc -catalog catalog.cat b.xsd

Now assume we also have an episode JAR:

a.jar!/META-INF/sun-jaxb.episode
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bindings version="2.1" xmlns="http://java.sun.com/xml/ns/jaxb">
  <bindings scd="x-schema::tns" xmlns:tns="http://maven-jaxb2-plugin/samples/episode/a">
    <schemaBindings map="false">
      <package name="maven_jaxb2_plugin.samples.episode.a"/>
    </schemaBindings>
    <bindings scd="~tns:AType">
      <class ref="maven_jaxb2_plugin.samples.episode.a.AType"/>
    </bindings>
    <bindings scd="~tns:A1Type">
      <class ref="maven_jaxb2_plugin.samples.episode.a.A1Type"/>
    </bindings>
    <bindings scd="~tns:A2EnumType">
      <typesafeEnumClass ref="maven_jaxb2_plugin.samples.episode.a.A2EnumType"/>
    </bindings>
  </bindings>
</bindings>

Now this fails:

xjc -extension -catalog catalog.cat b.xsd a.jar

The catalog does not work:

xjc -extension -catalog catalog.cat b.xsd a.jar
parsing a schema...
[ERROR] ...\test\a.xsd (Das System kann die angegebene Datei nicht finden) (eng. Could not find the file)
unknown location

Failed to parse a schema.

I can provide a minimal test project which reproduces this. Attachments do not work. Via mail? (Please ping me: valikov at gmx.net)



 Comments   
Comment by lexi [ 21/Jan/13 ]

I did some debugging and found out that in case no binding files are used, model loading opts to "speculative mode"

I traced it down to the DOMForest which calls the entity resolver with null publicId (whereas it is not null - the namespace is provided):

DOMForest.java
public Document parse( String systemId, boolean root ) throws SAXException, IOException {

        systemId = Options.normalizeSystemId(systemId);

        if( core.containsKey(systemId) )
            // this document has already been parsed. Just ignore.
            return core.get(systemId);
        
        InputSource is=null;
        
        // allow entity resolver to find the actual byte stream.
        if( entityResolver!=null )

// HERE:
            is = entityResolver.resolveEntity(null,systemId);
        if( is==null )
            is = new InputSource(systemId);
        
        // but we still use the original system Id as the key.
        return parse( systemId, is, root );
    }

If no episodes are provided, then no binding files are defined and ModelLoader opts to the "speculative" mode:

ModelLoader.java
public XSSchemaSet loadXMLSchema() throws SAXException {

        if( opt.strictCheck && !SchemaConstraintChecker.check(opt.getGrammars(),errorReceiver,opt.entityResolver, opt.disableXmlSecurity)) {
            // schema error. error should have been reported
            return null;
        }

        if(opt.getBindFiles().length==0) {
            // no external binding. try the speculative no DOMForest execution,
            // which is faster if the speculation succeeds.
            try {
                return createXSOMSpeculative();
            } catch( SpeculationFailure _ ) {
                // failed. go the slow way
            }
        }

        // the default slower way is to parse everything into DOM first.
        // so that we can take external annotations into account.
        DOMForest forest = buildDOMForest( new XMLSchemaInternalizationLogic() );
        return createXSOM(forest, scdBasedBindingSet);
    }

It seems to be something wrong with the DOMForest. It should not ignore the publicId.

Comment by phax [ 19/Jun/13 ]

I'm having the same problem in 2.2.7.
I was tracing it down to AbstractReferenceFinderImpl.startElement

The call to abstract method "findExternalResource" only returns the specified XSD path but totally ignores the publicID of the item (if present). The implementation to this method is in com.sun.tools.xjc.reader.xmlschema.parser.XMLSchemaInternalizationLogic$ReferenceFinder

And afterwards it seems to me, that the resolution of the artifact does not consider a catalog!
-> In my case this leads to the problem that the catalog file must contain an absolute path instead of a relative path!

Comment by lexi [ 06/Oct/14 ]

Here's a pull request which fixed it:

https://github.com/gf-metro/jaxb/pull/8





[JAXB-1001] Cannot pass language for generated Javadoc Created: 28/Jan/14  Updated: 03/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Michael Osipov Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Content of Javadoc depends on the locale of the developer machine. E.g., in my case it is de_DE but I need the language of the generated content to be in English. I cannot pass -Duser.language=en. Please add as switch to make this controlable.



 Comments   
Comment by Iaroslav Savytskyi [ 29/Jan/14 ]

I think the easiest way is to change user locale to English just before calling xjc. And if you need - you can switch it back afterwards.

Comment by Iaroslav Savytskyi [ 29/Jan/14 ]

If this solution is acceptable I'm going to close the issue.

Comment by Michael Osipov [ 29/Jan/14 ]

Actually, I can't. I do not use xjc directly but the JAXB Maven Plugin. I do not intend to modify Maven's environment just for one plugin.

Comment by puce [ 18/Mar/14 ]

Any workaround for this in a Jenkins started Maven build using the org.jvnet.jaxb2.maven2:maven-jaxb2-plugin Maven plugin?

Comment by puce [ 17/May/14 ]

This issue still persists and is very annoying. Any news?

Comment by Michael Osipov [ 17/May/14 ]

puce, no changes from Oracle.

Comment by lexi [ 03/Oct/14 ]

I've added the feature in the `maven-jaxb2-plugin`, see [MAVEN-JAXB2-PLUGIN-87].
Would be actually nice if XJC would have an option to switch the locale. I don't know how to do it with the command-line XJC. When calling it via java -jar then it should be possible via -Duser.language and co., but for the xjc.exe? No idea.





[JAXB-1031] JAXB 2.1.x generates errorneous episode File Created: 15/Jul/14  Updated: 03/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1.14, 2.1.16
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File sun-jaxb.episode    

 Description   

A user has reported that JAXB-XJC version 2.1.14 generates a bad episode file due to the - string contained in the internal version (v2.1.14-hudson-jaxb-ri-2.1-pushtomaven-240-SNAPSHOT). When this version is printed out in the comment, this makes XML invalid.

This also makes JAXB-984 or JAXB-1003 blockers since 2.1.14 is not usable and 2.1.15 and above have invalid POMs.



 Comments   
Comment by lexi [ 15/Jul/14 ]

Attached a sample file.

Note the comment:

  <!--

This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.1.14-hudson-jaxb-ri-2.1-pushtomaven-240--SNAPSHOT 
See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
Any modifications to this file will be lost upon recompilation of the source schema. 
Generated on: 2014.07.15 at 11:36:41 PM CEST 

  -->
Comment by lexi [ 15/Jul/14 ]

Same problem with 2.1.16:

  <!--

This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.1.16-hudson-jaxb-ri-2.1-pushtomaven-250--SNAPSHOT 
See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
Any modifications to this file will be lost upon recompilation of the source schema. 
Generated on: 2014.07.15 at 11:44:54 PM CEST 

  -->
Comment by lexi [ 15/Jul/14 ]

2.1.13 is not affected.

Comment by lexi [ 03/Oct/14 ]

This issue still persists in 2.1.17.





[JAXB-963] JAXB xjc crashes while parsing trivial 8-line XSD file when -binding is used together with -catalog Created: 12/Jun/13  Updated: 03/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.4u2
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: m_perdikeas Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 12.04.2, JDK 1.7.0_21


Tags: binding, catalog, jaxb, jaxb-xjc, xjc

 Description   

Below is the absolute trivial, minimal example that demonstrates the problem.

Three schema files: A.xsd, B.xsd, C.xsd in the following import configuration:

  • C.xsd imports A.xsd and B.xsd
  • B.xsd imports A.xsd

So A.xsd is imported directly by C.xsd and again indirectly through B.xsd. The problem occurs when trying to run xjc (ver. 2.2.4) on C.xsd when both a catalog and a binding file is used (even an empty one).

---------- FILE A.xsd
<schema targetNamespace="foo://a"
xmlns="http://www.w3.org/2001/XMLSchema">
<simpleType name="year">
<restriction base="dateTime">
<pattern value="\d

{4}

"/>
</restriction>
</simpleType>
</schema>

---------- FILE B.xsd
<schema targetNamespace="foo://b"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="foo://a" schemaLocation="boo://a.xsd"/>
</schema>

---------- FILE C.xsd
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="foo://c">
<import namespace="foo://a" schemaLocation="A.xsd"/>
<import namespace="foo://b" schemaLocation="B.xsd"/>
</schema>

---------- FILE catalog.xml
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<system systemId="boo://a.xsd" uri="A.xsd"/>
</catalog>

---------- FILE binding.xjb
<bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.1"/>

Given the above files, all placed in the same directory the below invocation succeeds:

xjc -d src -extension -catalog catalog.xml C.xsd

whereas the following invocation:

xjc -d src -extension -catalog catalog.xml C.xsd -b bindings.xjb

... fails with the bug-like message (pointing to some internal mess-up?):

parsing a schema...
[ERROR] 'year' is already defined
line 8 of file:/home/brutus/A.xsd

[ERROR] (related to above error) the first definition appears here
line 3 of file:/home/brutus/A.xsd

Failed to parse a schema.

All components of the above minimal reproduction are necessary to trigger the bug. If no binding file is used xjc parses correctly and generates code. If no catalog file is used xjc parses correctly and generates code. If both binding file an catalog are used xjc fails to parse. This is a blocking issue at least in my particular case as the XSD files are given and cannot be modified and I have to use both a catalog and a binding file (to get around other issues).



 Comments   
Comment by markzimmngc [ 20/Dec/13 ]

I am seeing this same issue with java version 1.7.0_45 and xjc 2.2.4-2 on RedHat.

Comment by lexi [ 03/Oct/14 ]

Related to or duplicate of https://java.net/jira/browse/JAXB-1045





[JAXB-1045] "Item" is already defined error with catalogs, bindings and mixed absolute and relative URLs Created: 28/Sep/14  Updated: 02/Oct/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive cd.zip     Zip Archive gml-v_3_1_1.zip    

 Description   

This is somewhat complex setup, please take a look at the prepared example (attached) first.

I am trying to do a clean compilation of the GML 3.1.1 schema using catalogs and binding files.

I've created local copies of files in the w3c and ogc folders and rewrite URLs using the following catalog file:

REWRITE_SYSTEM "http://www.w3.org" "w3c"
REWRITE_SYSTEM "http://schemas.opengis.net" "ogc"

In the GML schema there is one schema which imports SMIL via the absolute URL:

defaultStyle.xsd
<import namespace="http://www.w3.org/2001/SMIL20/" schemaLocation="http://schemas.opengis.net/gml/3.1.1/smil/smil20.xsd"/>

My understanding is that http://schemas.opengis.net/gml/3.1.1/smil/smil20.xsd will be resolved to ogc/gml/3.1.1/smil/smil20.xsd via catalog.

The smil20.xsd imports smil20-language.xsd via relative URL:

smil20.xsd
<import namespace="http://www.w3.org/2001/SMIL20/Language" schemaLocation="smil20-language.xsd"/>

The smil20-language.xsd imports the smil20.xsd also via relative URL:

smil20-language.xsd
<import namespace="http://www.w3.org/2001/SMIL20/" schemaLocation="smil20.xsd"/>

When I try to compile this I get the following stream of errors:

[ERROR] 'structureModuleAttrs' is already defined
  line 45 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 37 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'skipContentAttrs' is already defined
  line 51 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 45 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'alternateContentAttrs' is already defined
  line 58 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 51 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'nonNegativeDecimalType' is already defined
  line 66 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 58 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animate' is already defined
  line 66 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 66 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animatePrototype' is already defined
  line 72 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 67 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animNamedTargetAttrs' is already defined
  line 84 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 72 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animAddAccumAttrs' is already defined
  line 102 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 84 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animValuesAttrs' is already defined
  line 108 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 102 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animSetValuesAttrs' is already defined
  line 111 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 108 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animTargetAttrs' is already defined
  line 114 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 111 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animModeAttrs' is already defined
  line 125 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 114 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateMotion' is already defined
  line 125 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 125 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateMotionPrototype' is already defined
  line 131 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 126 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateColor' is already defined
  line 131 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 131 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateColorPrototype' is already defined
  line 137 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 132 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'set' is already defined
  line 137 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 137 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'setPrototype' is already defined
  line 145 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 138 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorAttrs' is already defined
  line 149 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 145 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorType' is already defined
  line 157 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 149 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorDefaultAttrs' is already defined
  line 161 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 157 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorDefaultType' is already defined
  line 169 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 161 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartTimingAttrs' is already defined
  line 172 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 169 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartTimingType' is already defined
  line 180 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 172 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartDefaultAttrs' is already defined
  line 183 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 180 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartDefaultType' is already defined
  line 191 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 183 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillTimingAttrs' is already defined
  line 194 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 191 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillTimingAttrsType' is already defined
  line 204 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 194 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillDefaultAttrs' is already defined
  line 207 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 204 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillDefaultType' is already defined
  line 217 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 207 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'beginEndTimingAttrs' is already defined
  line 221 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 217 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'durTimingAttrs' is already defined
  line 224 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 221 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'repeatTimingAttrs' is already defined
  line 228 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 224 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'deprecatedRepeatTiming' is already defined
  line 231 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 228 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'minMaxTimingAttrs' is already defined
  line 235 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 231 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

Failed to parse a schema.

Note that XJC complains about the identical URLs, also references the same lines (however in a wrong order which is a bit weird).

If I change both of the relative URLs in the SMIL schemas to absolute URLs, it does work. Of course, I don't want this workaround as I don't want to patch external schemas.

I've also reproduced it on a "reduced" test case with simple schemas (see the cd.zip attachment).

The problem arises only if bindings files are used. When compiling without bindings, it works (see success.bat and failure.bat in cd.zip). failure.bat gives the following error trace:

[ERROR] 'd' is already defined
  line 9 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

[ERROR] (related to above error) the first definition appears here
  line 9 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

[ERROR] 'DType' is already defined
  line 16 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

[ERROR] (related to above error) the first definition appears here
  line 10 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

Failed to parse a schema.

Lines are quite interesting. The element 'd' is reported two times on the same line. The type 'DType' is reported two times - one on the opening <complexType ...> tag of the type and once on the closing </schema> tag:

01<?xml version="1.0" encoding="UTF-8"?>
02<schema 
03	xmlns="http://www.w3.org/2001/XMLSchema"
04	targetNamespace="urn:d" elementFormDefault="qualified"
05	xmlns:d="urn:d"
06	xmlns:e="urn:e">
07
08	<import namespace="urn:e" schemaLocation="e.xsd"/>
09	<element name="d" type="d:DType"/>
10	<complexType name="DType">
11		<sequence>
12			<element name="s" type="string"/>
13			<element name="e" type="e:EType"/>
14		</sequence>
15	</complexType>
16</schema>

My guess is that the graph:

  • schema 1 -(absolute URL)-> schema 2
  • schema 2 -(relative URL)-> schema 3
  • schema 3 -(relative URL)-> schema 2

somehow causes problems with schema 2. I think the problem might be different paths to schema 2. The URLs are finally rewritten via catalog to the same URL but the same document gets parsed two times.

This is quite a showstopper for me at the moment. I am forced to patch schemas on a very big scale, which is extremely ugly.



 Comments   
Comment by lexi [ 02/Oct/14 ]

Please consider a fix in the https://github.com/gf-metro/jaxb/pull/7

The problem here is that when the entity resolver resolves some systemId, you get an input source with the stream AND a resolved systemId. Subsequent resolutions (when you for instance have an import or an include) will use this resolved system id. This may result in some schemas addressed by an unresolved and by a resolved system id - despite being placed in the same local source.

The fix is simple: when resolving, only provide the stream and don't change the system id (or public id) of the input source. This still works well - parsers take XML from the stream. And this corrects the problem since system id does not change.


I understand that we're talking customer-facing interface here so you probably have to carefully consider if you apply the fixes or not. I am persuaded that what I propose is the correct behaviour, so I will want to fix it anyway (in maven-jaxb2-plugin, at least). I think I can make workarounds via the entity resolver for JAXB-1044 and JAXB-1045 as it is basically the entity resolver logic which is changed here.
What I can't do is JAXB-1046 since it addresses the interna of the DOMForest which is not accessible. But I think this fix is not dangerous at all.

Please let me know what you think of the fixes and if we can work them into the XJC release.





[JAXB-1046] Catalog-resolved schema is not considered to be a part of compilation Created: 28/Sep/14  Updated: 02/Oct/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive cd.zip    

 Description   

Please see the cd.zip.

Assume http://www.ab.org/d.xsd is rewritten to ab/d.xsd via catalog:

REWRITE_SYSTEM "http://www.ab.org" "ab"

I want to customize the d.xsd so I do the following in the binding file:

	<jaxb:bindings schemaLocation="ab/d.xsd" 
		node="/xs:schema">
		<jaxb:schemaBindings>
			<jaxb:package name="org.ab.d"/>
		</jaxb:schemaBindings>
	</jaxb:bindings>

I get the following error message:

[ERROR] "file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1046/ab/d.xsd" is not a part of this compilation. Is this a mistake for "file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1046/ab/c.xsd"?
  line 13 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1046/cd.xjb

I would argue that ab/c.xsd is definitely a part of the compilation - even if resolved via catalog. Otherwise I'm forced to write the absolute URL in the binding's schemaLocation which is ugly.

This is also important because this issue prohibits reusage of binding files. Please let me explain.

Assume we habe two schemas a.xsd and b.xsd, b.xsd imports a.xsd via absolute URL http://www.ab.org/a.xsd.

We want to compile a.xsd in one compilation and b.xsd plus b.xsd in another.

Due to JAXB-1044 we can't compile http://www.ab.org/a.xsd directly (i.e. xjc http://www.ab.org/a.xsd -catalog a.cat).
Even when using a catalog, XJC still tries to download the file. So we have to compile the local copy xjc a.xsd. If we want to use a binding file to customize compilation, we have to write schemaLocation="a.xsd" in the binding file. Ok, all of this is more or less fine.

Now we want to compile b.xsd which imports http://www.ab.org/a.xsd. Now, it would be cool to reuse the binding file from the first compilation. But that binding file says schemaLocation="a.xsd" bit our second compilation needs schemaLocation="http://www.ab.org/a.xsd". Dead end. We have to write another a.xjb with the only difference being relative vs. absolute URL.

One solution would have been to compile http://www.ab.org/a.xsd instead of a.xsd in the first compilation. But as I pointed, this does not work due to JAXB-1044.

FYI I am perfectly aware of features like SCD and episodes. However there are scenarios, where SCD and episodes are not suitable or don't work as desired. For instance, SCD/episodes do not handle vendor customization elements at the moment.



 Comments   
Comment by lexi [ 02/Oct/14 ]

Please consider a fix in https://github.com/gf-metro/jaxb/pull/7 (see the DOMForest).

When resolving URIs, add BOTH the original URI as well as the resolved URI to the id/documents map - with the same document, of course.





[JAXB-1052] Marshaller.marshall throws NPE if an adapter adapts a non-null bound type to null value of another type with single xmlValue annotation Created: 01/Oct/14  Updated: 01/Oct/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: coconnor Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is basically a very narrow corner-case of JAXB-415, but I thought it might be better to track it as a new bug. I actually discovered it in Scala, but was able to reproduce it with the following Java (which, I tested worked in MOXy - heresy I know).

Also, It doesn't occur if,
1) you add an attribute to Bar
2) you change the single xmlValue to be an xmlElement

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Foo {

@XmlElement
@XmlJavaTypeAdapter(TestAdapter.class)
private Optional<Bar> v;
public Foo()
{
}
public Foo(Optional<Bar> v)

{ this.v = v; }

public static void main(String[] args) throws Exception

{ Marshaller m = JAXBContext.newInstance(Bar.class, Foo.class).createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true); m.marshal(new Foo(Optional.of(new Bar("foo"))), System.out); }

}

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Bar {
@XmlValue
private String v;

public Bar() {
}

public Bar(String v)

{ this.v = v; }

}

public class TestAdapter extends XmlAdapter<Bar,Optional<Bar>>
{
public Optional<Bar> unmarshal(Bar v) throws Exception

{ return null; }

public Bar marshal(Optional<Bar> v) throws Exception

{ return null; }

}



 Comments   
Comment by coconnor [ 01/Oct/14 ]

I used,
guava = "com.google.guava" % "guava" % "18.0"

It might also work if you adapt from completely separate type, but it seemed appropriate to demonstrate the utility I am deriving from this use-case.

Comment by coconnor [ 01/Oct/14 ]

And this is the stacktrace:

Exception in thread "main" java.lang.NullPointerException
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:54)
at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:36)
at java.lang.reflect.Field.get(Field.java:379)
at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.get(Accessor.java:266)
at com.sun.xml.bind.v2.runtime.reflect.Accessor.getUnadapted(Accessor.java:143)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.hasValue(TransducedAccessor.java:251)
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl$TransducerImpl.writeLeafElement(RuntimeClassInfoImpl.java:409)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.writeLeafElement(TransducedAccessor.java:256)
at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serializeBody(SingleElementLeafProperty.java:130)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:361)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:342)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)
at org.caoilte.atomizer.model.Foo.main(Foo.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)





[JAXB-1043] Content of collection properties lost during Unmarshalling Created: 26/Sep/14  Updated: 30/Sep/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: killerchamb Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Bug occurs on version 2.2.10-b140310.1920



 Description   

Recent versions of JAXB handle collection properties differently than before. An empty collection is created at the beginning, and set into the target bean, and then elements are added to the collection, without any interaction with the bean.

So if the bean for instance makes a private copy of the collection when the setter is called, the content of the collection is lost. See the unit test below.

Issue occurs with version 2.2.10-b140310.1920


package test.serialization.jaxb;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;

import java.io.StringReader;
import java.io.StringWriter;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.annotation.XmlRootElement;

import org.junit.Test;

@XmlRootElement
public class A {

	protected List<String> list;

	public List<String> getList() {
		return list;
	}

	public void setList(List<String> list) {
		// Store the list content in a private copy
		this.list = new ArrayList<>(list);
	}

	@Test
	public void test() throws Exception {
		A a = new A();
		a.setList(Arrays.asList("something"));
		
		JAXBContext ctx = JAXBContext.newInstance(A.class);

		StringWriter writer = new StringWriter();
		
		ctx.createMarshaller().marshal(a, writer);
		
		String text = writer.toString();
		System.out.println(text);
		
		A a2 = (A) ctx.createUnmarshaller().unmarshal(new StringReader(text));
		assertNotNull(a2.getList());
		assertEquals(1, a2.getList().size());
		assertEquals("something", a2.getList().get(0));
	}
	
}



 Comments   
Comment by laune [ 26/Sep/14 ]

Consider;
class A1

{ protected List<String> list = new ArrayList<>(); //... }

works, as does
class A2 {
//...
public void setList(List<String> list)

{ this.list = list; }

//...
}
With class A as shown, the client must provide the implementation for List<String>, apparently leaving it up to him whether it's going to be a LinkedList, an ArrayList or whaterver. But that object isn't returned!

Which, after all, would make a client write code like
a.setList( new ArrayList<String>() );
for(String s: ..)

{ ;a.setList( a.getList().add() ); }

because it isn't guaranteed that what you set is what you get; resulting in a markedly inefficient code.

It may be regrettable that JAXB'S behaviour has changed, but I wouldn't expect it to work with a class according to the pattern of class A.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

Hi @killerchamb,

Why do you think this is a bug?

In any case you can clone the collection after unmarshalling, right?

I'm going to close this as 'Not a bug'

Comment by killerchamb [ 30/Sep/14 ]

Hi, and thank you for looking at this.

I agree that the new behaviour is not a bug, not more than the previous behaviour at least. It's just that it does not work in a few more cases than before, when the getter/setter methods of a class modify the data. When you can alter the source code of the serialized classes it is very easy to fix, when you cannot it blocks you.

I let you close the ticket, at least there will be a trace of the discussion.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

The only thing I can imagine is, that we can set already populated collection.
I'll give a try.

Thanks for reporting.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

@me -> https://java.net/jira/browse/JAXB-948





[JAXB-1050] Wrong package test.t1 in txw2 Created: 28/Sep/14  Updated: 28/Sep/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Java files in txw2/src/test/java say they're in test.t1 whereas they are in t1.



 Comments   
Comment by lexi [ 28/Sep/14 ]

PR: https://github.com/gf-metro/jaxb/pull/5





[JAXB-1047] SCD bindings do not support custom/vendor customization elements Created: 28/Sep/14  Updated: 28/Sep/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I wrote a number of XJC plugins, some of these plugins can be customized via binding files.

For instance, I can do the following:

<jaxb:bindings version="1.0" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" 
	xmlns:xs="http://www.w3.org/2001/XMLSchema" 
	xmlns:jsonix="http://jsonix.highsource.org/customizations"
	jaxb:extensionBindingPrefixes="jsonix">

	<jaxb:bindings schemaLocation="w3c/1999/xlink.xsd" node="/xs:schema">
		<jsonix:packageMapping packageName="org.hisrc.w3c.xlink.v_1_0" spaceName="XLink_1_0"/>
	</jaxb:bindings>
</jaxb:bindings>

If my Jsonix plugin is activated, XJC will know that jsonix:packageMapping is a customization element for Jsonix (plugin API allows saying what your customization namespace URI is and which local names you expect).

SCD seems to be a more advanced way to address schema elements. I.e.

	<jaxb:bindings scd="x-schema::xlink" xmlns:xlink="http://www.w3.org/1999/xlink" ... />

addresses the XLink schema logically via namespace URI. Forget the files, this is perfect. Much more versatile than schemaLocation and node. I guess episodes would not work without SCD in first place. For my scenarios it would for instance help with JAXB-1047.

My problem is that SCD does not allow custom elements. So this:

<jaxb:bindings version="1.0" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" 
	xmlns:xs="http://www.w3.org/2001/XMLSchema" 
	xmlns:jsonix="http://jsonix.highsource.org/customizations"
	jaxb:extensionBindingPrefixes="jsonix">

	<jaxb:bindings scd="x-schema::xlink" xmlns:xlink="http://www.w3.org/1999/xlink">
		<jsonix:packageMapping packageName="org.hisrc.w3c.xlink.v_1_0" spaceName="XLink_1_0"/>
	</jaxb:bindings>
</jaxb:bindings>

I get the following error:

[ERROR] Error while parsing schema(s).Location [ file:/C:/Projects/workspaces/ogc-ng/w3c-schemas/xlink/1999/src/main/resources/xlink-v_1_0.jsonix.xjb{8,89}].
org.xml.sax.SAXParseException; systemId: file:/C:/Projects/workspaces/ogc-ng/w3c-schemas/xlink/1999/src/main/resources/xlink-v_1_0.jsonix.xjb; lineNumber: 8; columnNumber: 89; cvc-elt.1: Cannot find the declaration of element 'jsonix:packageMapping'.

Clearly, SCD does not process custom configuration elements whereas schemaLocation plus node do process.






[JAXB-1041] inheritence & XmlRootElement Created: 19/Sep/14  Updated: 20/Sep/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: diorcety Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If B class extends the class A, both annotate with XmlType, and C class annotate with XmlType & XmlRootElement, C contains a field of type A.

The Xml can looks like that
<C>
<A xsi:type="B"/>
</C>
.
Now if A is a XmlRootElement the Xml could looks like that
<A xsi:type="B"/>

Currently, jaxb is not able to marshall that (B class doesn't have XmlRootElement annotation),
but is able to unmarshall that.



 Comments   
Comment by laune [ 20/Sep/14 ]

This works according to the specification.

It isn't possible to marshal an element that isn't annotated with XmlRootElement, which is the way the marshaller learns about the local name and the namespace of the root element.

It would be possible to create a JAXBElement and marshal this - see the JAvadoc.

This issue should be closed.

Comment by diorcety [ 20/Sep/14 ]

Ok i didn't know that was a specification restriction. This mean that jaxb can unmarshall that without any trick, but can't marshall without using JAXBElement.

Comment by laune [ 20/Sep/14 ]

It's more a consequence of: "If there is no information about an XML element's name and namespace: how can you create (i.e. marshal) it`?" It's a gap that can't be filled even if the spec's authors would have wanted to.

Comment by diorcety [ 20/Sep/14 ]

According to this post http://blog.bdoughan.com/2010/11/jaxb-and-inheritance-using-xsitype.html?showComment=1354657419516#c7344877388280882872, this is the behaviour of Moxy





[JAXB-1040] JAnnotationUse causes NPE in getAnnotationMembers() Created: 12/Sep/14  Updated: 12/Sep/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dmitry Katsubo Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If memberValues field is never added a parameter, then calling JAnnotationUse#getAnnotationMembers() causes NullPointerException. This is actual for annotations like `@XmlMixed`, which by definition don't have params.






[JAXB-1039] Call to JPackage.annotations() causes empty package-info.java to be generated Created: 12/Sep/14  Updated: 12/Sep/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Dmitry Katsubo Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently getter JPackage.annotations() is called, private field annotations is set to not-null value, causing empty {{package-info.java} to be generated.

The line JPackage.java:443

if(annotations!=null || jdoc!=null)

should be changed to:

if((annotations!=null && !annotations.isEmpty) || jdoc!=null)





[JAXB-1037] Duplicate (after name mapping) field name causes IllegalArgumentException Created: 06/Sep/14  Updated: 08/Sep/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: laune Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux ubuntu 14.04, jdk1.8.0_20



 Description   

Actually, the xjc version identifies itself as
$ xjc -version
xjc 2.2.8-b130911.1802
But this funny bug tracker tells me that this version 2.2.8 doesn't exist! So how come it is delivered together with the official Java JDK 1.8.0_20???

Compile the XML Schema file below to see the error. Note that "xx" and "XX" cause the crash, whereas "xx" and "Xx" produce an error message (as would be expected in the other case as well).

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="what:ever"
elementFormDefault="qualified">

<xs:complexType name="Media">
<xs:sequence>
<xs:element name="id" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ID" type="xs:ID"/>
</xs:complexType>

</xs:schema>



 Comments   
Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

It's was my fault with versions. It's OK now. And I've updated the bug affected version.

Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

I think the bug is that we throw error in this case. ID and id generates different names for getters/setters. So there shouldn't be a problem. I'm going to refactor XJC code to use java.beans.Introspector.





[JAXB-1036] Jaxb cannot unmarshal files containing hash (#) in name. Created: 24/Aug/14  Updated: 08/Sep/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: michalborek Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Jaxb Unmarshaller has unmarshal(File) method.

When passing a file that contains # in name (e.g. some#name.xml), the part of name after the hash is treated as URL anchor and is not recognized properly.

The problem is caused by improper implementation of this method, which internally uses unmarshal(URL) method invocation.



 Comments   
Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

Confirming the bug.
Thanks for reporting.





[JAXB-929] DOMForest.getOneDocument() should only return documents from "rootDocuments" Set and not from "core" Map Created: 16/Nov/12  Updated: 08/Sep/14

Status: In Progress
Project: jaxb
Component/s: xjc
Affects Version/s: not determined, JWSDP1.1 (JAXB1.0), JWSDP1.2 (JAXB1.0.1), JWSDP1.3 (JAXB1.0.2), JWSDP1.4 (JAXB1.0.3), JWSDP1.5 (JAXB1.0.4), JWSDP1.6 (JAXB1.0.5), 2.0 FCS, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12, 2.1.13, 2.1.14, 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.3u1, 2.2.3u2, 2.2.4, 2.2.4u1, 2.2.4u2, 2.2.5, 2.2.6, 2.2.7, 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Eugenio De Hoyos (IBM) Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ant Builder, Windows


Attachments: Zip Archive JAXB-929 - 4 test cases.zip    
Tags: JAXB, globalBindings, xjc

 Description   

JAXB fails to generate correct schema 100% of the time because it sometimes fails to interpret the bindings file that we specify. Given an identical startup environment (including input files and build sequence), the output of our JAXB generated java-source code is not consistent from one run to the next.

We debugged the problem using the JAXB source code and we determined that getOneDocument() inside com.sun.tools.xjc.reader.internalizer.DOMForest sometimes returns a document that is not specified as a root document but that is instead referenced by a root document. Such indirectly specified document is an xsd:include in our root documents, and we deliberately decided not to specify a target namespace for it as part of our design. As a result of this document not having a target namespace, Internalizer.move() fails to correctly bind the globalBindings file to the schema forest by arbitrarily choosing a document from the forest. Whenever JAXB tries to look for the global bindings at a later point in time, the schema cannot be found in the forest.

Whenever getOneDocument() returns an object that can be found in the rootDocuments Set of DOMForest, the global bindings file is correctly attached, and JAXB generates java source code correctly as expected. Whenever getOneDocument() returns an object not in rootDocuments but that is part of the core Map of DOMForest, the bindings file is not correctly attached, and the java source code is not correctly generated. In the current code, the document selected is not predictable because getOneDocument() iterates over a HashSet, which does not specify iteration order by design, thus explaining why the generator is not consistent in its failures. That is, in some runs a root schema is chosen, and in other runs a non-root schema is chosen.

We suggest changing line 225 of DOMForest.java inside getOneDocument() from

for (Document dom : core.values())

{ . . . }

to

for (String k : rootDocuments)

{ Document dom = core.get(k); . . . }

 Comments   
Comment by Iaroslav Savytskyi [ 19/Nov/12 ]

Hi, Eugenio,

Thanks for submission. Can you please provide some simple test to reproduce this issue?

Thank you.


Iaroslav

Comment by Eugenio De Hoyos (IBM) [ 19/Nov/12 ]

Hi Iaroslav,

I provided 4 simple tests that demonstrate when the issue occurs.

As I generated the simplified code for these tests I found some more details that I did not find before. The issue only occurs when there's an xsd:annotation element directly inside xsd:schema. Having an xsd:annotation element inside other nested elements does not trigger the problem.

For instance, the sample tests show that removing either the xsd:include or the xsd:annotation element from the following file results in the bindings file being correctly handled.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" jaxb:version="2.1" targetNamespace="http://www.example.org/" xmlns="http://www.example.org/" >

<xsd:include schemaLocation="include1.xsd"/>

<xsd:annotation/>

<xsd:complexType name="TestClass.Type"/>

</xsd:schema>

Also, note that the information that I gave in the original description concerning target namespaces is not relevant. The problem occurs with include files regardless of the declared target namespace.

However, the fact that the problem occurs when getOneDocument() selects an include file rather than a "root" file is still true.

I hope this helps debug the issue.





[JAXB-1035] Locator is not set for elements without attributes Created: 19/Aug/14  Updated: 19/Aug/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: michalborek Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A locator field, defined as follows:
@XmlType(name = "selector")
public class Selector

{ @XmlLocation @XmlTransient public Locator locator; @XmlValue public String value; }

is ignored in classes, that are treated as leaves (in XML).

In effect, having node <selector>text</selector> we are unable to get line of <selector> xml node (locator is null).

When we add some dummy attribute to that class, locator is being set.

I've checked the source code and the problem is with the fact that when arbitrary node contains only text content, it is treated as Leaf, and there is no consideration whether there is Locator attribute defined or not.






[JAXB-1034] Add/respect non-proxy hosts settings Created: 29/Jul/14  Updated: 29/Jul/14

Status: Open
Project: jaxb
Component/s: maven-plugin
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Michael Osipov Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

One can pass a HTTP proxy but not non-proxy hosts. If HTTP is retrieved from settings.xml, sub element nonProxyHosts is ignored but must be respected.

A patch can be provided.

This relates to JAX_WS-1154.



 Comments   
Comment by Michael Osipov [ 29/Jul/14 ]

This is actually crucial in a corporate environment.

Comment by Michael Osipov [ 29/Jul/14 ]

Please close, wrong project.





[JAXB-1033] disableXmlSecurity doesn't work properly Created: 17/Jul/14  Updated: 17/Jul/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: miroslav.kos Assignee: miroslav.kos
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

disableXmlSecurity doesn't work properly when Security Manager enabled:

javax.xml.parsers.ParserConfigurationException: FEATURE_SECURE_PROCESSING:
Cannot set the feature to false when security manager is present.
at com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:122)
at com.sun.xml.bind.v2.util.XmlFactory.createParserFactory(XmlFactory.java:128)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getXMLReader(UnmarshallerImpl.java:154)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:172)






[JAXB-1032] "Unique Particle Attribution" exception when choice is A,B or A+B Created: 03/Jul/14  Updated: 15/Jul/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tiou2 Assignee: lexi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I currently have a choice of either having 'field1' OR 'field2'. I need to make additionally possible having both 'field1' AND 'field2' as well. So the choice is to have either field1, field2 or both field1 and field2.

I have the following structure in an XSD:

<xsd:choice>
	<xsd:element name="field1" nillable="false">
		<xsd:simpleType>
			<xsd:restriction base="xsd:int"/>
		</xsd:simpleType>
	</xsd:element>
	<xsd:element name="field2" nillable="false">
		<xsd:simpleType>
			<xsd:restriction base="xsd:string">
				<xsd:minLength value="1"/>
			</xsd:restriction>
		</xsd:simpleType>
	</xsd:element>
</xsd:choice>

Adding a sequence with both field1 and field2 causes the exception:

	(....)
		</xsd:element>
		<xsd:sequence>
			<xsd:element name="field1" nillable="false">
				<xsd:simpleType>
					<xsd:restriction base="xsd:int"/>
				</xsd:simpleType>
			</xsd:element>
			<xsd:element name="field2" nillable="false">
				<xsd:simpleType>
					<xsd:restriction base="xsd:string">
					<xsd:minLength value="1"/>
				</xsd:restriction>
			</xsd:simpleType>
		</xsd:element>
	</xsd:sequence>
</xsd:choice>

The exception I'm getting is:

[ERROR] Error while parsing schema(s).Location [ file:...removed...].
org.xml.sax.SAXParseException; systemId: ...removed...; lineNumber: X; columnNumber: Y; cos-nonambig: "ns1":field1 and "ns1":field1 (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)


 Comments   
Comment by Tiou2 [ 03/Jul/14 ]

A workaround is to add another field within the sequence, unfortunately it cannot be made optional:

	<xsd:choice>
		<xsd:element name="oid" type="xsd:int" nillable="false"/>
		<xsd:element name="klantnummer" type="xsd:string" nillable="false"/>
	</xsd:choice>
	<xsd:choice>
		<xsd:element name="field1" type="xsd:int" nillable="false"/>
		<xsd:element name="field2" type="xsd:string" nillable="false"/>
		<xsd:sequence>
			<xsd:element name="dont_use"/>
			<xsd:element name="field1" type="xsd:int" nillable="false"/>
			<xsd:element name="field2" type="xsd:string" nillable="false"/>
		</xsd:sequence>
	</xsd:choice>
Comment by lexi [ 15/Jul/14 ]

Moved to JAXB sind this is not a Maven plugin issue.





[JAXB-1003]  Invalid pom: jaxb-xjc 2.1.16 has a wrong dependency to jaxb-core 2.1.16 Created: 06/Mar/14  Updated: 15/Jul/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.1.16
Fix Version/s: None

Type: Bug Priority: Major
Reporter: roos Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: dependency, jaxb-xjc, pom

 Description   

The pom states a dependency to jaxb-core 2.1.6 which does not exist for the 2.1.x versions.

This bug for 2.1.16 was already reported in a comment of JAXB-984, and one stated to fix it, but the bug is closed now (without a fix).
So nobody is currently able to use 2.1.17, unless they use a fixed private pom.

Please fix all the versions stated in JAXB-984, too.



 Comments   
Comment by roos [ 06/Mar/14 ]

Typos in the comment. 2.1.6 > 2.1.16, 2.1.17 > 2.1.16. Unable to edit the text, sorry.

Comment by Iaroslav Savytskyi [ 07/Mar/14 ]

Hi,

I have pushed jaxb-core 2.1.14. Can you use it as workaround?

Comment by lexi [ 15/Jul/14 ]

Workaround:

		<dependency>
			<groupId>com.sun.xml.bind</groupId>
			<artifactId>jaxb-impl</artifactId>
			<version>${jaxb21.version}</version>
			<exclusions>
				<exclusion>
					<groupId>com.sun.xml.bind</groupId>
					<artifactId>jaxb-core</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>com.sun.xml.bind</groupId>
			<artifactId>jaxb-xjc</artifactId>
			<version>${jaxb21.version}</version>
			<exclusions>
				<exclusion>
					<groupId>com.sun.xml.bind</groupId>
					<artifactId>jaxb-core</artifactId>
				</exclusion>
			</exclusions>
		</dependency>




[JAXB-996] Slow performance of Unmarshaller when reading xsd:any element Created: 24/Dec/13  Updated: 14/Jul/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcb Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, standard JDK 1.7.0_04



 Description   

I had already reported this issue to Oracle, but I don't think it got attention (and maybe I was reporting it to the wrong people anyway). On the users@jaxb.java.net mailing list Iaroslav guided me here. So below is a copy/paste of my bug report. In short: unmarshalling xml files with a lot of 'any' elements takes an unacceptable long time in JDK 1.7u4.

Date Created: Thu Mar 28 08:28:09 MST 2013
Type: bug
Customer Name: Pieter Buzing
Customer Email: Buzing@...
SDN ID:
status: Waiting
Category: jaxb-xsd
Subcategory: runtime
Company: Riscure BV
release: 1.0.4
hardware: x64
OSversion: windows_7
priority: 3
Synopsis: Performance degradation between java 7u3 and 7u4 for xml
parsing of "xsd:any"
Description:
FULL PRODUCT VERSION :
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b22) Java HotSpot(TM)
64-Bit Server VM (build 23.0-b21, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
We observe a performance degradation between java 7u3 and 7u4 with
regard to the xml parsing of an "xsd:any" element with JAXB2. Also
later java updates have the same poor performance.

Given:

  • an xsd schema which contains an "xsd:any" element and which is
    compiled with xjc (version 2.2.4)
  • an xml file that conforms to the above xsd schema and contains (a lot
    of) <xsd:any> elements
  • a java class that unmarshals the above xml file
  • a Windows 7 computer with both jdk 7u3 and a later update installed

When we run the java unmarshal code with jdk1.7.0_04\bin\java.exe (7u4)
we observe that the required time is at least twice the runtime needed
by jdk1.7.0_03\bin\java.exe (7u3).

REGRESSION. Last worked in version 1.0.4

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Prepare an xsd file with an xs:any element (like in the comments in
the java code), compiling it with xjc.
2. Prepare a matching xml file that contains (a lot of) xs:any elements
(see also the comments in the java file).
3. Compile and run java code that unmarshals the xml data (like the
supplied example code).
4. Observe that running the code with jdk7u3 is at least twice as fast
compared to later updates.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The expected behavior would be an equal runtime for both java 7u3 and
7u4.
ACTUAL -
We observed a performance difference between different java runtime
environments:

java version = 1.7.0_03
.file size = 1613 bytes, read took 36 ms

java version = 1.7.0_04
.file size = 1613 bytes, read took 75 ms

When we increase the size of the xml file (or read multiple xml files)
the relative performance difference grows. Also for later updates like
7u17 we see the same performance degradation compared to 7u3.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.InputStream;
import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
import anyexample.Root;
import anyexample.Root.Anyproperties;

/**
This code demonstrates a performance bug in java 7u4. Steps to
replicate this bug:

1. Save and compile this xsd schema:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:element name='Root'>
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="unbounded"
name="anyproperties">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"
/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

The code assumes that the resulting class files are stored in a
directory called anyexample.

2. Store the following xml file as 'anyprops.xml':
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Root>
<anyproperties>
<Prop1>0</Prop1>
<Prop2>Inverse</Prop2>
<Prop3>bits</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>1</Prop1>
<Prop2>out</Prop2>
<Prop3>bits</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>3</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>4</Prop1>
<Prop2>bla</Prop2>
<Prop3>bar</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>5</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>6</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo1</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>7</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo2</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>8</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo3</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>9</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo4</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>10</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo5</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
</Root>

3. Run the code below with both jdk7u3 and jdk7u4 (or later) and
observe a significant performance difference.
*/
public class AnyPropertiesTest {

private JAXBContext anyContext;
private Unmarshaller anyUnmarshaller;

public static final String PATH = "anyprops.xml";

public AnyPropertiesTest() {
System.out.println("java version = " +
System.getProperty("java.version"));
try {
if (anyContext == null)

{ anyContext = JAXBContext.newInstance(Root.class); anyUnmarshaller = anyContext.createUnmarshaller(); }

} catch (JAXBException e)

{ e.printStackTrace(); }

}

public void testAny()

{ long startTime = System.nanoTime(); File inputFile = new File(PATH); List<Anyproperties> propertiesList = getProperties(inputFile); long duration = (System.nanoTime() - startTime) / 1_000_000; String s = String.format("read %d properties in %d ms", propertiesList.size(), duration); System.out.println(s); }

private List<Anyproperties> getProperties(File path) {
List<Anyproperties> properties;

try

{ System.out.printf("file size = %d bytes, ", path.length()); properties = read(new FileInputStream(path)); }

catch (JAXBException e)

{ System.out.println(String.format( "File '%s' could not be read by JAXB: might not be a valid XML file", path.getAbsolutePath())); properties = null; }

catch (FileNotFoundException e)

{ // Impossible as path was obtained from listFiles String errorMessage = String.format("File '%s' obtained by File.listFiles() does not exist", path.getAbsolutePath()); throw new RuntimeException(errorMessage, e); }

return properties;
}

private synchronized List<Anyproperties> read(InputStream stream)
throws JAXBException

{ List<Anyproperties> templates = null; long startTime = System.nanoTime(); //It is the unmarshall method that takes a considerable amount of time on java 7u4, compared to 7u3 Root root = (Root) anyUnmarshaller.unmarshal(stream); long duration = (System.nanoTime() - startTime)/1_000_000; System.out.printf("read took %d ms\n", duration); templates = (List<Anyproperties>) root.getAnyproperties(); return templates; }

public static void main(String[] argv)

{ AnyPropertiesTest test = new AnyPropertiesTest(); test.testAny(); }

}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
In order to deal with this issue we ship our product with java 7u3.
Upgrading to update 4 or later has a considerable performance impact
(we use large xml files).
The obvious solution is to avoid <xsd:any> elements, but this is not
always feasible.



 Comments   
Comment by ilyaz [ 01/May/14 ]

This issue has not yet been addressed but is still very important to us (I'm from the same company as the reporter of this issue).
It is now blocking our migration from Java7 to Java8, because in a critical feature of our product some of the options shown to our users in the user interface are defined in XML. JDK 7u4+ makes the reading (and therefore the perceived rendering) too slow for our users.

Furthermore, there are some bug fixes in JDK 7u4+ (such as the file explorer crashing in Windows when users sort an open file dialog by date) that we cannot provide to our users because of this issue.

Is any work on this issue expected?

Comment by elena-lorena [ 14/Jul/14 ]

Could you please update us if there is any planning to fix this issue in the coming release(s)?
We have started to migrate our projects to Java 8 and this issue is still blocking for us... (I'm from the same company as pcb and Ilyaz)
Your feedback would be much appreciated.
Thank you!





[JAXB-1030] Marshal/Unmarshal not symmetric for Strings with newline characters CR LF Created: 10/Jul/14  Updated: 10/Jul/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.4u2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: barney2k7 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jaxb 2.2.4-2 in Oracle jdk 7u60



 Description   

We've recently discovered an issue with marshal/unmarshal operations not being symmetric for strings containing newline characters (CR, LF or CRLF) (i.e. the resulting string after a marshal/unmarshal cycle isn't what the original string was).
Since XML parsers must normalize attribute values by replacing newline characters with spaces (reference: http://www.w3.org/TR/REC-xml/#AVNormalize), newline characters need to be escaped properly, but there doesn't seem to be a 'standard' way to tell a Marshaller to do this. Interestingly, this is only an issue if a StreamResult is used. If a DOMResult plus a Transformer is used, newline characters are actually escaped properly.
I'll attach a test case, which shows both ways to do this, with only 'testDomAndTransform' working properly so far.

Note that a very similar issue (JAXB-449) has been filed in the past and is marked as fixed. This doesn't actually seem to be the case, as the test case attached to that issue is still failing.



 Comments   
Comment by barney2k7 [ 10/Jul/14 ]

Here's the test case (not sure how i could have attached this as a file...):

import java.io.StringReader;
import java.io.StringWriter;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMResult;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;

import junit.framework.TestCase;

import org.w3c.dom.Document;

public class CrLfMarshalUnmarshalTest extends TestCase {
private static final String VALUE = "abc\r\nd\re\nf";
private Bean fElem;
private Marshaller fMarshaller;
private Unmarshaller fUnmarshaller;

@Override
protected void setUp() throws Exception

{ super.setUp(); JAXBContext ctx = JAXBContext.newInstance(Bean.class); fMarshaller = ctx.createMarshaller(); fUnmarshaller = ctx.createUnmarshaller(); fElem = new Bean(); fElem.setAttributeString(VALUE); fElem.setElementString(VALUE); }

public void testWriter() throws Exception

{ StringWriter sw = new StringWriter(); fMarshaller.marshal(fElem, sw); String resultXml = sw.toString(); System.out.println(resultXml); Bean resultElem = (Bean) fUnmarshaller.unmarshal(new StringReader(resultXml)); assertEquals(VALUE, resultElem.getAttributeString()); assertEquals(VALUE, resultElem.getElementString()); }

public void testDomAndTransform() throws Exception

{ StringWriter sw = new StringWriter(); DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); DocumentBuilder db = dbf.newDocumentBuilder(); Document d = db.newDocument(); DOMResult result = new DOMResult(d); fMarshaller.marshal(fElem, result); Transformer tf = TransformerFactory.newInstance().newTransformer(); tf.transform(new DOMSource(d), new StreamResult(sw)); String resultXml = sw.toString(); System.out.println(resultXml); Bean resultElem = (Bean) fUnmarshaller.unmarshal(new StringReader(resultXml)); assertEquals(VALUE, resultElem.getAttributeString()); assertEquals(VALUE, resultElem.getElementString()); }

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder =

{"fElementString", "fAttributeString"}

)
@XmlRootElement(name = "Bean")
public static class Bean {

@XmlElement(name = "ElementString")
protected String fElementString;

@XmlAttribute(name = "AttributeString")
protected String fAttributeString;

public String getElementString()

{ return fElementString; }

public void setElementString(String elementString)

{ fElementString = elementString; }

public String getAttributeString()

{ return fAttributeString; }

public void setAttributeString(String attributeString)

{ fAttributeString = attributeString; }

}
}





[JAXB-1029] Incorrect marshalling of object with overridden properties Created: 08/Jul/14  Updated: 09/Jul/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: vtkhir Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_03"
jaxb 2.2.7



 Description   
Parent.java
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Parent {
    private String field;

    @XmlElement(name = "field")
    public String getField() {
        return field;
    }

    public void setField(String field) {
        this.field = field;
    }
}
Child.java
@XmlRootElement(name = "Node")
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Child extends Parent {
    @Override
    @XmlElement(name = "overridedField")
    public String getField() {
        return super.getField();
    }

    public void setField(String field) {
        super.setField(field);
    }
}

Marshalling using jaxb 2.2.7:

<Node><field>test</field><overridedField>test</overridedField></Node>

jaxb 2.1.13:

<Node><overridedField>test</overridedField></Node>

Property overriding was fixed in JAXB-804 but issue remained in case when child class doesn't contains the field. The only option to get round with property access type is to add field in the Child class



 Comments   
Comment by Iaroslav Savytskyi [ 09/Jul/14 ]

Hi vtkhir,

Thank you for reporting. This looks like a bug. I'll take a look asap I'll be able to.


Best regards.
Iaroslav





[JAXB-1026] Running XJC with BOTH a binding file and a catalog that re-writes system ID's can lead to multiple type declaration errors Created: 19/Jun/14  Updated: 19/Jun/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.9
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dkulp Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When calling XJC with using a catalog that does a re-write of the SystemID:

REWRITE_SYSTEM "http://foo.blah.com/MySchema.xsd" "MyNewLocation.xsd"

AND there is a binding file added (it can be an empty binding file or a binding file with a globalBinding), and the schema ends up in a circular import loop, it can result in "already defined" errors.

The root cause is on line 296 of DOMForest (xjc version 2.2.11). The InputSource returned from:

 if( entityResolver!=null )
            is = entityResolver.resolveEntity(null,systemId);

could have a new systemId. However, when it calls the parse on line 301, it passes the old system id. That is then used as the key for the call to "core.add" (line 383).

Note: if you DON'T us a binding file, this is not a problem as the optimized code path for that does not suffer from this issue. In that case, line 342 of NGCCRuntimeEx properly calls the source.getSystemId() to get the system ID that it then uses.



 Comments   
Comment by dkulp [ 19/Jun/14 ]

I cannot find an option to attach a file to this issue that includes a test case.

A test case that demonstrates the problem can be found at:

http://dankulp.com/JAXB-1026.tar.gz





[JAXB-1025] Single schema works but not multiple schema Created: 07/Jun/14  Updated: 07/Jun/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lulseged Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 8.1 Enterprise



 Description   

Validation works with single schema but does not work with multiple schema. Java objects created by xjc are same. My tests works when it is a single schema but gives validation error when I use multiple schema, cvc-elt.1: Cannot find the declaration of element 'itinerary'.

There is no single difference between single and multiple schema except it is divided in number of schemas.

Why is validation failing?

I have used 2.2.7 and 2.2.11-SNAPSHOT. Gives the same error.

I can provide a maven project that can demonstrate this case.

I will appreciate any help.

BR
Lulseged

For single:

Source source = new StreamSource(getClass().getResourceAsStream("/xsd/itinerary.xsd");

For multiple:
Source[] source = new StreamSource[]
{
new StreamSource(getClass().getResourceAsStream("/xsd/travel.xsd")),
new StreamSource(getClass().getResourceAsStream("/xsd/plane.xsd")),
new StreamSource(getClass().getResourceAsStream("/xsd/itinerary.xsd"))
};

Schema schema = schemaFactory.newSchema(source);

When using

Single schema:
itinerary.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" targetNamespace="http://example.org/"
elementFormDefault="qualified" attributeFormDefault="qualified">

<xsd:element name="travel" type="e:travel-type" />

<xsd:complexType name="travel-type" abstract="true">
<xsd:sequence>
<xsd:element name="origin" type="xsd:string" />
<xsd:element name="destination" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>

<!-- plane -->
<xsd:element name="plane" type="e:plane-type" substitutionGroup="e:travel" />

<xsd:complexType name="plane-type">
<xsd:complexContent>
<xsd:extension base="e:travel-type">
<xsd:sequence>
<xsd:element name="flightNumber" type="xsd:int" />
<xsd:element name="meal" type="xsd:string" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<!-- itinerary -->
<xsd:element name="itinerary" type="e:itinerary-type" />

<xsd:complexType name="itinerary-type">
<xsd:sequence>
<xsd:element ref="e:travel" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>

</xsd:schema>

Multiple schema:
travel.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" targetNamespace="http://example.org/"
elementFormDefault="qualified" attributeFormDefault="qualified">

<xs:element name="travel" type="e:travel-type" />

<xs:complexType name="travel-type" abstract="true">
<xs:sequence>
<xs:element name="origin" type="xs:string" />
<xs:element name="destination" type="xs:string" />
</xs:sequence>
</xs:complexType>

</xs:schema>

itinerary.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" xmlns="http://example.org/"
targetNamespace="http://example.org/" elementFormDefault="qualified">

<xs:include schemaLocation="travel.xsd" />

<xs:include schemaLocation="plane.xsd" />

<xs:element name="itinerary" type="e:itinerary-type" />

<xs:complexType name="itinerary-type">
<xs:sequence>
<xs:element ref="e:travel" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:schema>

plane.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" targetNamespace="http://example.org/"
elementFormDefault="qualified" attributeFormDefault="qualified">

<xs:include schemaLocation="travel.xsd" />

<xs:element name="plane" type="e:plane-type" substitutionGroup="e:travel" />

<xs:complexType name="plane-type">
<xs:complexContent>
<xs:extension base="e:travel-type">
<xs:sequence>
<xs:element name="flightNumber" type="xs:int" />
<xs:element name="meal" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>






[JAXB-1021] When an element have same name that his element ancestor, jvc generate bad java classes, with a parent and a son with the same name. Created: 13/May/14  Updated: 13/May/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jpsanchez Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64,


Tags: element, name, same

 Description   

If you have en element with the same name that his parent, jvc run without problems but generate bad java classes.
If you tray to binding the name, then jvc generate a run time error like:

D:\PCBCK\Java\jaxb\jaxb-ri-2.2.7\samples\aod>xjc -nv -verbose messages.xsd -b bindingset.xml
Exception in thread "main" java.lang.IllegalArgumentException: Illegal class inheritance loop.
Outer class TargetSpeedElement may not subclass from inner class:
<<classnale>>
at com.sun.codemodel.internal.JDefinedClass._extends(JDefinedClass.java:257)
at com.sun.tools.internal.xjc.generator.bean.ImplStructureStrategy$1._extends(ImplStructureStrategy.java:104)
at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:197)
at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:151)
at com.sun.tools.internal.xjc.model.Model.generateCode(Model.java:275)
at com.sun.tools.internal.xjc.Driver.run(Driver.java:342)
at com.sun.tools.internal.xjc.Driver.run(Driver.java:184)
at com.sun.tools.internal.xjc.Driver._main(Driver.java:107)
at com.sun.tools.internal.xjc.Driver.access$000(Driver.java:64)
at com.sun.tools.internal.xjc.Driver$1.run(Driver.java:87)






[JAXB-1019] Invalid boolean values added to lists as 'false' (part 2) Created: 12/May/14  Updated: 12/May/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.4
Fix Version/s: 2.2.5

Type: Bug Priority: Major
Reporter: kylape Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by kylape [ 12/May/14 ]

This is a continuation of JAXB-849. While that jira fixed some cases of illegal xs:boolean values, there are still others that return false when they should return null, namely values that start with t and f. It looks like changing these two lines to return null would do the trick:

https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L270
https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L285

In addition, if the string literals "t" and "f" are passed in, this will cause an unmarshalling error:

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 1
        at java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:203) [rt.jar:1.7.0_55]
        at java.lang.StringBuilder.charAt(StringBuilder.java:72) [rt.jar:1.7.0_55]
        at com.sun.xml.bind.DatatypeConverterImpl._parseBoolean(DatatypeConverterImpl.java:260)

This would map to either of these two lines on master:

https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L264
https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L278

Comment by kylape [ 12/May/14 ]

Pull request for this issue (with added test case): https://github.com/gf-metro/jaxb/pull/2





[JAXB-1018] NPE when using mixed element and episode Created: 10/May/14  Updated: 10/May/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.4u2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: MichelHartmann Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I'm trying to compile two XSD files using an episode file:

The first one:
xjc -d out -episode schema_1.episode schema_1.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://example.com/schema_1"
	   xmlns:ns1="http://example.com/schema_1"
	   xmlns:xs="http://www.w3.org/2001/XMLSchema">

	<xs:element name="Element">
		<xs:complexType>
			<xs:simpleContent>
				<xs:extension base="xs:string">
					<xs:attribute name="Attribute" type="xs:string" use="optional" />
				</xs:extension>
			</xs:simpleContent>
		</xs:complexType>
	</xs:element>

</xs:schema>

Then I try to compile the second file:
xjc -verbose -d out schema_2.xsd -extension -b schema_1.episode

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema 
	targetNamespace="http://example.com/schema_2"
	xmlns:ns1="http://example.com/schema_1"
	xmlns:ns2="http://example.com/schema_2"
	xmlns:xs="http://www.w3.org/2001/XMLSchema">

	<xs:import namespace="http://example.com/schema_1" schemaLocation="schema_1.xsd" />

	<xs:complexType name="Abstract" abstract="true" mixed="true">
		<xs:sequence>
			<xs:element ref="ns1:Element" minOccurs="0" maxOccurs="unbounded" />
		</xs:sequence>
	</xs:complexType>

</xs:schema>

This will result in.

Exception in thread "main" java.lang.NullPointerException
        at com.sun.tools.internal.xjc.generator.bean.field.AbstractField.annotateReference(AbstractField.java:173)
        at com.sun.tools.internal.xjc.generator.bean.field.AbstractField.annotate(AbstractField.java:146)
        at com.sun.tools.internal.xjc.generator.bean.field.AbstractListField.generate(AbstractListField.java:114)
        at com.sun.tools.internal.xjc.generator.bean.field.UntypedListField.<init>(UntypedListField.java:97)
        at com.sun.tools.internal.xjc.generator.bean.field.UntypedListFieldRenderer.generate(UntypedListFieldRenderer.java:62)
        at com.sun.tools.internal.xjc.generator.bean.field.DefaultFieldRenderer.generate(DefaultFieldRenderer.java:67)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generateFieldDecl(BeanGenerator.java:759)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generateClassBody(BeanGenerator.java:540)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:243)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:151)
        at com.sun.tools.internal.xjc.model.Model.generateCode(Model.java:275)
        at com.sun.tools.internal.xjc.Driver.run(Driver.java:342)
        at com.sun.tools.internal.xjc.Driver.run(Driver.java:184)
        at com.sun.tools.internal.xjc.Driver._main(Driver.java:107)
        at com.sun.tools.internal.xjc.Driver.access$000(Driver.java:64)
        at com.sun.tools.internal.xjc.Driver$1.run(Driver.java:87)

If I drop the mixed="true" or if I place both elements in one XSD the compilation will succeed.






[JAXB-1017] Messages.properties: Incorrect value for CONFLICTING_XML_ELEMENT_MAPPING Created: 07/May/14  Updated: 07/May/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.5, 2.2.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: soilworker Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When JAXB wants to read the string for following error:

CONFLICTING_XML_ELEMENT_MAPPING = \
    The element name '{'{0}'}'{1} has more than one mapping.

the original error will be lost because the formatting of the string fails and a new exception will be thrown:

java.lang.IllegalArgumentException: can't parse argument number ''{0}''
	at java.text.MessageFormat.makeFormat(MessageFormat.java:1339)[:1.6.0_25]
	at java.text.MessageFormat.applyPattern(MessageFormat.java:458)[:1.6.0_25]
	at java.text.MessageFormat.<init>(MessageFormat.java:350)[:1.6.0_25]
	at java.text.MessageFormat.format(MessageFormat.java:811)[:1.6.0_25]
	at com.sun.xml.bind.v2.model.impl.Messages.format(Messages.java:133)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.TypeInfoSetImpl.add(TypeInfoSetImpl.java:306)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.RegistryInfoImpl.<init>(RegistryInfoImpl.java:121)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.ModelBuilder.addRegistry(ModelBuilder.java:362)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:332)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:460)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:298)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:141)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1163)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:145)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_25]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)[:1.6.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[:1.6.0_25]
	at java.lang.reflect.Method.invoke(Method.java:597)[:1.6.0_25]
	at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)[:1.6.0_25]
	at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)[:1.6.0_25]
	at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)[:1.6.0_25]
	at org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:267)[cxf-api-2.7.4.jar:2.7.4]
	at org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:265)[cxf-api-2.7.4.jar:2.7.4]
	at java.security.AccessController.doPrivileged(Native Method)[:1.6.0_25]
	at org.apache.cxf.common.jaxb.JAXBContextCache.createContext(JAXBContextCache.java:265)[cxf-api-2.7.4.jar:2.7.4]
	at org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:172)[cxf-api-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:464)[cxf-rt-databinding-jaxb-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:330)[cxf-rt-databinding-jaxb-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:478)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:690)[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:540)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:252)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:205)[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]
	at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)[cxf-rt-frontend-simple-2.7.4.jar:2.7.4]
	at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:90)[cxf-rt-frontend-simple-2.7.4.jar:2.7.4]
	at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:156)[cxf-rt-frontend-simple-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:156)[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]

I used the version 2.2.5 but I've been taking a look to the newest version(2.2.7 and 2.2.7-b63) and there the message string is still the same. So I think this issue is still present



 Comments   
Comment by soilworker [ 07/May/14 ]

I see now that it only appears with the german language(Messages_de.properties).





[JAXB-1015] Quote character is not replaced by U+0022 during marshalling Created: 29/Apr/14  Updated: 07/May/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: j.malek Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java1.8u05 + Maven3



 Description   

There is a problem when marshalling object that contains XML string with quote character.
Character " is not replaced by '"'.
Here is JUnit test that fails:

public class WrappedXMLMarshallingTest {

    @Test
    public void shouldMarshallWrappedXML() throws JAXBException {
        // given
        Message message = new Message("<frame type=\"1.0\">test</frame>");
        Marshaller marshaller = createMessageMarshaller();
        ByteArrayOutputStream result = new ByteArrayOutputStream();

        // when
        marshaller.marshal(message, result);

        // then
        String expectedResult =
                "<message><content>&lt;frame type=&quot;1.0&quot;&gt;test&lt;/frame&gt;</content></message>";
        assertEquals(expectedResult, result.toString());
    }

    private Marshaller createMessageMarshaller() throws JAXBException {
        JAXBContext context = JAXBContext.newInstance(Message.class);
        Marshaller marshaller = context.createMarshaller();
        marshaller.setProperty(Marshaller.JAXB_ENCODING, "UTF-8");
        marshaller.setProperty(Marshaller.JAXB_FRAGMENT, true);
        return marshaller;
    }

    @XmlAccessorType(XmlAccessType.FIELD)
    @XmlType(name = "", propOrder = {
            "content"
    })
    @XmlRootElement(name = "message")
    static class Message {
        private String content;

        private Message() {
        }

        private Message(String content) {
            this.content = content;
        }

        String content() {
            return content;
        }
    }
}


 Comments   
Comment by j.malek [ 07/May/14 ]

It looks like I made a mistake, """ is used to allow attribute values to contains double quotes, in this scenario quote is used in xml element so marshalling works fine.





[JAXB-1016] Importing elements from schema with no namespace into schema with a namespace fails Created: 30/Apr/14  Updated: 30/Apr/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: markjenner Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 or Linux, Java 6u18



 Description   

I have a complex schema most of which uses the empty namespace, except for one file, CDQobjects.xsd. The elements in there need to rely on some elements from the empty namespace and imports the appropriate file CreditCurves.xsd. However when I run xjc on the schema it fails with error:

parsing a schema...
[ERROR] src-resolve: Cannot resolve the name 'RelativeCreditSpreadCurve' to a(n) 'element declaration' component.
line 13 of file:/opt/app/ci/workspace/trunk/domain/pricing/src/main/xsd/CDQobjects.xsd

[ERROR] src-resolve: Cannot resolve the name 'CreditSpreadCurve' to a(n) 'element declaration' component.
line 14 of file:/opt/app/ci/workspace/trunk/domain/pricing/src/main/xsd/CDQobjects.xsd

However, if I remove all of the other schema files and leave just the one with the error and the one it relies on, without editing them:

  • CDQobjects.xsd
  • CreditCurves.xsd

Then xjc creates the java classes correctly.

I tried to whittle down the test case to a simpler schema to make it easier for you to reproduce the problem but I ran into some strange and seemingly improbable dependencies:

  • I got the test set down to just 3 files, and the addition the 3rd (unreferenced) xsd file would cause the error to appear. However, when I moved this schema to a different dir to package them up, I noticed that the error did not occur on the copy!
  • In a different test, I changed the name of CreditCurves.xsd to BeforeCDQobjectsCreditCurves.xsd and the error went away when I used xjc on Windows 7, but still occurred on our build server on Linux.

The error seems to consistently occur on Windows with the package of Schema files that I have attached. I hope you can reproduce it locally and then just delete bits until you get to a simple case that reliably fails and helps you uncover the problem.

Ah. I just started looking for the attach button to include the schema and there doesn't seem to be one! How should I send you the test case?






[JAXB-917] Add support for XML schema facets and documentation Created: 04/Sep/12  Updated: 20/Apr/14

Status: In Progress
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.2.3
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: yossico Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 19
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all platforms; java se 7


Attachments: Java Archive File jaxb-facets-0.3.jar     Java Archive File jaxb-facets-1.0.jar    
Tags: jaxb

 Description   

While working closely with quite a few enterprise customers implementing ESBs/BPMs I realized the quality bar for xml schemas is constantly rising. It is no longer acceptable to have xml schema with no documentation and xsd facets.

One open source implementation supporting xsd facets can be found here: http://www.infosys.tuwien.ac.at/staff/hummer/tools/jaxb-facets.html but unfortunately it is not maintained as part of JAXB.

There are many good reasons to keep on using Java 1st approach for schema generation and it better not be neglected and supply such fundamental capabilities.
More relevant links:
http://jaxb.java.net/guide/Generating_Schema_that_you_want.html
http://java.net/projects/jaxb/lists/users/archive/2007-06/message/36



 Comments   
Comment by Iaroslav Savytskyi [ 05/Sep/12 ]

Hi, yossico,

To start working with your code we neen you to sign Oracle Contributor Agreement (OCA). Here are some links:

FAQ: http://www.oracle.com/technetwork/oca-faq-405384.pdf
OCA: http://glassfish.java.net/public/GovernancePolicy.html

Thanks a lot.

Comment by yossico [ 05/Sep/12 ]

Hi Iaroslav,

Just to make it clear, the code i have attached is not mine. It is an open source that is managed through this web site: http://www.infosys.tuwien.ac.at/staff/hummer/tools/jaxb-facets.html. Thus, if this code is planned to be used for this solution, it needs to comply with the license agreement published through that web site (contact: Mr. Waldemar Hummer; email: hummer@infosys.tuwien.ac.at).

Comment by yossico [ 09/Oct/12 ]

Hi,

I signed the form and sent it over a while ago.
To what Java release does Oracle plans to accomodate this enhancement?

Thanks,
Yossi C.

Comment by Iaroslav Savytskyi [ 08/Nov/12 ]

Hi, yossico,
I will look at this and hope if everything will be OK we will include it to JAXB 2.2.7 release.

Comment by whummer [ 09/Nov/12 ]

Version 1.0 of JAXB-Facets

Comment by whummer [ 09/Nov/12 ]

Hi,

there is a more recent, updated version 1.0 of JAXB-Facets available, which contains some minor bug fixes and API changes. I am attaching the most recent version.

EDIT: do we need to sign the agreement for each uploaded version..?

Thanks,
Waldemar H.

Comment by blaise_doughan [ 12/Dec/12 ]

Is JAXB-Facets compatible with Bean Validation (JSR-303)? If not changing it to be would help adoption and make it easier to include in a future version of the JAXB specification.

Comment by pellcorp [ 13/Dec/12 ]

it is not compatible and i would agree changing to use jsr 303 annotations would be a great idea. There is a new github repo for jaxb-facets and we are working on test coverage and refinements. i am using jsr 303 in gwt at work so there is definate synergy there. i am on leave until mid january but would be interested in seeing how easy the Facets and Min Max stuff could be refactored to use equivalent jsr 303 annotations.

only question to ponder is do we use the javax.validation annotations directly?

github is: https://github.com/whummer/jaxb-facets

Comment by pellcorp [ 13/Dec/12 ]

a very relevant forum post has already been made on this topic of jsr 303 compatibility which I was not aware of.

http://java.net/projects/jaxb/lists/dev/archive/2011-01/message/2

so compatibility might not be so easy because jsr 303 does not have the same level of validation as xsd and thus jaxb-facets.

Comment by whummer [ 13/Dec/12 ]

However, we do seek integration with JSR-303 in terms of the facets validation.

The @Facets/@MinOccurs/@MaxOccurs annotations are now annotated with @javax.validation.Constraint(validatedBy=...) and we will provide a custom validator implementation. This way, the Facets validation can be seamlessly integrated into the JSR-303 validation framework.

Comment by yossico [ 03/Feb/13 ]

Hello,

What is the estimated delivery time for this feature?
Is there a plan to incorporate this feature to the JAXB specification?

Thanks,
Yossi C.

Comment by puce [ 15/Feb/13 ]

+1 for adding this feature and making it compatible to JSR-303 resp. JSR-349 (Bean Validation 1.1)

Comment by schrepfler [ 24/Mar/13 ]

This would be a really great extension as it will fill a large hole on how we document services.
It would seem however the latest code is being developed here and not on the whummer repo?
https://github.com/pellcorp/jaxb-facets

Comment by tgeor [ 19/Jun/13 ]

In which version are you planning to include this feature? I think this extension is a must have in JAXB

Comment by schrepfler [ 19/Jun/13 ]

Also, would this only track schemagen or xjc as well?

Comment by whummer [ 21/Jun/13 ]

To avoid confusion, the repository we are working on is here:

https://github.com/whummer/jaxb-facets

We have just finished another round of refactoring, and in terms of features we believe that the code is ready for release. How shall we proceed..?

Comment by yossico [ 01/Aug/13 ]

Hello,

Any progress with this issue?
What is the target release for this enhancement?
When should we expect it?

Your reply to these questions will be greatly appreciated.

Thanks,
Yossi C.

Comment by Iaroslav Savytskyi [ 05/Aug/13 ]

I'm trying to contact the owner of jaxb-facets project. We need all projects' contributors to sign OCA. After that we'll be able to do something.

Comment by yossico [ 06/Nov/13 ]

Hello,

This is a gentle reminder

Do you know by now what is the target release for this enhancement? Release date?
Do you continually track bug-fixes/updates from jaxb-facets web site (https://github.com/whummer/jaxb-facets)?

Thanks,
Yossi C.

Comment by sytzevk [ 19/Jan/14 ]

I see that the Java-first approach is (going to be) covered, but what about wsdl-first ? Does the jaxb-facets project aim to support the jaxb java code generation annotated with facets ?

Comment by whummer [ 31/Jan/14 ]

We have added initial support for wsimport in the current release version (2.2.6-facets-1.1.0), which you can check out from github: https://github.com/whummer/jaxb-facets

@Iaroslav, is there any progress concerning the contributor agreements - when can we continue to merge this into the reference impl.? thanks

Comment by schrepfler [ 27/Mar/14 ]

Hi, any updates on progress or when can we expect to see this part of the official jaxb?

Comment by Iaroslav Savytskyi [ 31/Mar/14 ]

Hi,

We are working on the Bean Validation (JSR 303) support. I hope it will cover requirements of current request.

Comment by schrepfler [ 01/Apr/14 ]

Are you planning to release documentation and facet support at the same time? It might be good to decouple if facet+jsr303/349 will take longer to implement.

Comment by davidkarlsen2 [ 20/Apr/14 ]

BTW: There is a project here which can generate JSR303 annotations from the schemas: https://github.com/krasa/krasa-jaxb-tools if interested.





[JAXB-1013] xjc:substitutable does not work in JAXB 2.2.7 anymore Created: 16/Apr/14  Updated: 16/Apr/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Niels Bertram Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The original Jira JAXB-289 proposed a solution to fix the substitution resulting in rather inconvenient JAXBElement<T> used when the type was abstract and part of a substitution group. Also the documentation at https://jaxb.java.net/2.2.7/docs/ch05.html#substitutable suggests that this feature should work.

However it does not seem to work with JAXB-RI 2.2.7 anymore.

I have attached the original test files from JAXB-289 as simple maven project using the maven-jaxb22-plugin. The project contains a default profile to show the output that is undesirable. You can run and inspect using following maven command:

mvn clean install

The profile substitutable will just trigger a generation using the annotated schema as per documentation and the Jira issue. You can run this build with following maven command:

mvn clean install -Psubstitutable

The exact stack trace error is:

com.sun.istack.SAXParseException2; systemId: file:///.../base/Model.xsd; lineNumber: 8; columnNumber: 37; compiler was unable to honor this substitutable customization. It is attached to a wrong place, or its inconsistent with other bindings.
...
com.sun.istack.SAXParseException2; systemId: file:///.../base/Model.xsd; lineNumber: 5; columnNumber: 43; (the above customization is attached to the following location in the schema)


 Comments   
Comment by Niels Bertram [ 16/Apr/14 ]

Tried to attach the example testcase but have no access. You can find the example on GitHub at https://github.com/bertramn/jaxb-substitutable-example .





[JAXB-1012] No default constructor found on class javax.xml.bind.JAXBElement - Need know why Created: 07/Apr/14  Updated: 08/Apr/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: vanekl Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win 7 64b, JavaSE 7


Tags: unmarshalling

 Description   

Hi,

I have generated Java code from XSD, using xjc tool, sheme is here : http://dd.eionet.europa.eu/schemas/id2011850eu/AirQualityReporting.xsd

I can marshall XML from it, and its valid against XSD: http://www.valachnet.cz/lvanek/0/CZ_E2a_hourly.xml

While unmarshall back, I get exception:

com.sun.xml.bind.v2.ClassFactory create0
INFO: No default constructor found on class javax.xml.bind.JAXBElement
java.lang.NoSuchMethodException: javax.xml.bind.JAXBElement.<init>()
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.getDeclaredConstructor(Unknown Source)
at com.sun.xml.bind.v2.ClassFactory.create0(ClassFactory.java:104)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.createInstance(ClassBeanInfoImpl.java:286)

I discovered, that JAXB creates in method 'ClassBeanInfoImpl::createInstance'
jaxbType = javax.xml.bind.JAXBElement - But it's not have default constructor.

I need to know which XML fragment causes my problem, but NoSuchMethodException isn't informative.
It is possible surround calling: bean = ClassFactory.create0(jaxbType); in 'ClassBeanInfoImpl::createInstance' method with try/catch and throw more descriptive exception ?

Bye,
Lumir Vanek



 Comments   
Comment by laune [ 07/Apr/14 ]

The indicated XML schema loads several other xsd files from the net and does not compile, needing customizations. Please provide the customization as you have used it. Also, the top level element of the XML file gml:FeatureCollection is not defined in the schema file. Also, complete code to reproduce the unmarshalling should be provided.

Hoewever, it's very likely that this is a case of incomplete customization and/or JAXB use and should not be discussed in this JIRA, where bubs are reported. Please use the user list for further discussion since JIRA is rather inconvenient for this.

Comment by vanekl [ 08/Apr/14 ]

Hi,
my customization is:

http://www.valachnet.cz/lvanek/0/bindings.xjb

Ant script, that generate Java code is:

http://www.valachnet.cz/lvanek/0/generate_jaxb_code.xml

And unmarshalling code:

import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBElement;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.ValidationEvent;
import javax.xml.bind.ValidationEventHandler;
import javax.xml.transform.stream.StreamSource;
import javax.xml.validation.Schema;
import javax.xml.validation.SchemaFactory;
import javax.xml.validation.Validator;

import org.xml.sax.SAXException;

import net.opengis.gml._3.FeatureCollectionType;

public static void main(String[] args)
{
try
{
System.out.println("Creating JAXB Context");
final JAXBContext jaxbContext = JAXBContext.newInstance(FeatureCollectionType.class);

/*

  • Input XML
    */
    String fileName = ".\\output
    CZ_E2a_hourly.xml";

/*

  • Loading XSD
    */
    System.out.println("Loading XSD");
    SchemaFactory schemaFactory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
    // Schema schema = schemaFactory.newSchema(new File("..\\AirQualityReportingModel\\XSD
    AirQualityReporting_0.3.7c.xsd"));
    Schema schema = schemaFactory.newSchema(new URL("http://dd.eionet.europa.eu/schemas/id2011850eu/AirQualityReporting.xsd"));

/*

  • Validation
    */
    System.out.println("Validating " + fileName + "...");

try

{ Validator validator = schema.newValidator(); validator.validate(new StreamSource(new File(fileName))); System.out.println("OK"); }

catch (Exception e)

{ e.printStackTrace(); return; }

/*

  • Unmarsalling
    */
    final Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();
    unmarshaller.setSchema(schema);

unmarshaller.setEventHandler(new ValidationEventHandler()
{
@Override
public boolean handleEvent(ValidationEvent event)
{
System.out.println(event.getMessage());
return true;
}}
);

JAXBElement<FeatureCollectionType> featureCollection = unmarshaller.unmarshal(new StreamSource(fileName), FeatureCollectionType.class);
System.out.println(featureCollection.getName());

final FeatureCollectionType featureCollectionType = featureCollection.getValue();
System.out.println(featureCollectionType.getDescription());
}
catch (JAXBException | SAXException | MalformedURLException e)

{ e.printStackTrace(); }

}

Bye,
Lumir

Comment by laune [ 08/Apr/14 ]

Works for me, using data as posted and xjc and java from /extra/JDK7u21/jdk1.7.0_21/. Some other effect has caused validation warnings which I haven't investigated. (I'll not continue this thread via JIRA.)

Comment by vanekl [ 08/Apr/14 ]

Hi,
after some hours of debugging I found cause of problem:

Class (generated by jxc): net.opengis.om._2.OMObservationType

have declared:

@XmlElement(required = true, type = JAXBElement.class)
protected Object result;

After removing "type = JAXBElement.class" Unmashalling works fine.

I am still belived, that throwing more descriptive exceptions (ideally containing tag name)
in this case would be welcomed by JAXB users.

class UnmarshallingContext::createInstance( JaxBeanInfo beanInfo ) may be good place to cath
NoSuchMethodException and send it to Loader.reportError().

You can close this issue, thanks for help.

Best Regards,
Lumir Vanek





[JAXB-828] schemagen generates schemas for the xml namespace "http://www.w3.org/XML/1998/namespace" Created: 13/Apr/11  Updated: 05/Apr/14

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.1.11, 2.1.12, 2.1.13, 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.3u1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: matunos Assignee: Martin Grebac
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File package-info.java     Java Source File SampleElement.java     XML File schema1.xsd     XML File schema2.xsd     File sun-jaxb.episode    

 Description   

If I have defined classes which use elements from the standard XML namespace "http://www.w3.org/XML/1998/namespace", and then run those through schemagen, schemagen will create a separate xsd for that namespace, and also include bindings for that namespace in the episode file, if I choose to generate one of those.

The problem is that this namespace is treated special in XML (including by xjc), but not by schemagen. For example, the resultant episode file is invalid because it contains a prefix mapping such as this:
xmlns:tns="http://www.w3.org/XML/1998/namespace"

That's illegal (you can't bind that namespace to any prefix other than 'xml'), and in fact, xjc knows this; xjc will reject the episode file if I try to include it in an invocation.

Furthermore, the generated schema for my own namespace now has an <xs:import> with a schemaLocation of the generated xml schema, rather than the well-defined schema location.

Since there is a well-defined schema already for this namespace (at http://www.w3.org/2001/xml.xsd), there is no reason for schemagen to generate one when it's generating a schema from source code. Instead, I think it should generate something like this:

<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>

...and then not generate another xsd for the items in the code.

The comments at http://www.java.net/node/645497 (5 years old) appear to agree with me.

A more generic approach would be to allow me to tell schemagen not generate xsds for certain namespaces of my choice, and instead to just insert an <xs:import> either with no schemaLocation, or with a schemaLocation of my choice (no schemaLocation would work for consumers who are using an XMLCatalog to find the appropriate schemas).



 Comments   
Comment by matunos [ 13/Apr/11 ]

I've attached 5 files. The 2 java files are for a java package named 'schemagenSample'. The two xsds and the episode file are the results of running the following command:

$ schemagen.sh -cp . -episode sun-jaxb.episode schemagenSample/*

Comment by Martin Grebac [ 22/Nov/11 ]

Changing to enhancement, not really an issue.

Comment by jinahya [ 05/Apr/14 ]

I've never use `xml:xxx` attributes so far. And I just got this issue with Java 1.8.0.
What if anyone is intending to use those generated (two xsd documents) directly on HTTP output?





[JAXB-1010] allow generate episode to use if-exists attribute Created: 22/May/12  Updated: 03/Apr/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: tdrury Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We forked the jaxb maven plugin a while back and I'm trying to replace it with the latest "open-source, off-the-shelf" version. The earlier maven plugin didn't generate episode files correctly (or at all?) so we wrote our own plugin to generate episodes. One nice attribute in episode files if the "if-exists" attribute as shown below:

<bindings if-exists="true" scd="~tns:Foo">
<class ref="com.acme.common.Foo"/>
</bindings>

This eliminates the need to re-import every schema when compiler later schemas with this episode file.



 Comments   
Comment by lexi [ 19/Jan/13 ]

I'm not quite sure, how is this related to the maven plugin for JAXB.

Comment by emystein [ 27/Mar/13 ]

tdrury could share your fork that generates episodes with if-exists attribute on bindings?
Thanks in advance,

Comment by tdrury [ 28/Mar/13 ]

I didn't fork the plugin. Instead, I wrote my own maven plugin that generates episode files from the package-info.java file that xjc creates.

Comment by lexi [ 03/Apr/14 ]

Hi Iaroslav,

here's an idea for bindings customization. Was filed in my maven-jaxb2-plugin project, but is clearly not in scope there.

Best wishes,
/Alexey





[JAXB-983] JAXB does not support meta class annotations Created: 14/Oct/13  Updated: 01/Apr/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Przemyslaw Bielicki Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jaxb

 Description   

JAXB reads annotations directly from scanned classes by calling directly java.lang.Class.getAnnotation(Class<A>) This means that Java classes must be annotated directly by e.g. @XmlRootElement, @XmlType etc.

JAXB should read also meta annotations of scanned class annotations i.e. let's take the following example:

Bean.java
@XmlRootElement
@XmlType
// ... other annotations
@Retention(RUNTIME)
@Target(TYPE)
public @interface Bean {
}

and then a Java bean:

Input.java
@Bean
public class Input {

  BigInteger amount;
  Account account;
  // remainder omitted
}

In such case if you execute this:

Main.java
Input input = new Input();
input.setAmount(new BigInteger(1000));
// remainder omitted
JAXBContext.newInstance(Input.class).createMarshaller().marshal(input, System.out);

you will get an error:

Exception in thread "main" javax.xml.bind.MarshalException
 - with linked exception:
[com.sun.istack.SAXException2: unable to marshal type "Input" as an element 
because it is missing an @XmlRootElement annotation]

IMHO it's a bug. JAXB should support annotations annotated with javax.xml.bind annotations. I will send you a patch for class annotations but it should be also the case for fields and methods, I think.



 Comments   
Comment by Przemyslaw Bielicki [ 14/Oct/13 ]

patch sent to dev@jaxb.java.net

Comment by Przemyslaw Bielicki [ 01/Apr/14 ]

patch available on github: https://github.com/pbielicki/jaxb/commit/4bafc09fc6a2be203329e3e2423bf9143698828b





[JAXB-981] Customize default local name for XML element, type and property Created: 10/Oct/13  Updated: 01/Apr/14

Status: Reopened
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Przemyslaw Bielicki Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jaxb

 Description   

The following class:

CalculatorInput.java
@XmlRootElement
public class CalculatorInput {

  BigDecimal leftOperand;
  BigDecimal rightOperand;
  Operation operation;

  // setters and getters omitted for brevity

will be serialized by JAXB to the following XML:

CalculatorInput.xml
<calculatorInput>
<operation>MULTIPLY</operation>
<leftOperand>150</leftOperand>
<rightOperand>7</rightOperand>
</calculatorInput>

It is desirable to change the default element, type and property naming convention by the user e.g. one would like to have one of the following outputs (without touching CalculatorInput.java):

CalculatorInput.xml
<CALCULATOR_INPUT>
<OPERATION>MULTIPLY</OPERATION>
<LEFT_OPERAND>150</LEFT_OPERAND>
<RIGHT_OPERAND>7</RIGHT_OPERAND>
</CALCULATOR_INPUT>

or

CalculatorInput.xml
<CalculatorInput>
<Operation>MULTIPLY</Operation>
<LeftOperand>150</LeftOperand>
<RightOperand>7</RightOperand>
</CalculatorInput>

At this moment JAXB does not allow to customize default behavior to obtain results above.

The same problem applies when you annotate your class as @XmlType.



 Comments   
Comment by Przemyslaw Bielicki [ 10/Oct/13 ]

sent patch with a solution proposal to dev@jaxb.java.net

Comment by Iaroslav Savytskyi [ 10/Oct/13 ]

It's possible to customize mapping names with "name" attribute of annotations.
e.g. @XmlRootElement (name="CALCULATOR_INPUT")
Fields can be annotated as @XmlElement(name="LeftOperand")

Comment by laune [ 10/Oct/13 ]

Do you have a proposal how to define these renaming actions in a way that is reasonably simple to handle at run time? Note that you say "without touching <the Java source file>". Also, note that this must work both ways, i.e., for unmarshalling, too.

A very simple XSLT would achieve such transformations easily - most certainly taking less time to write than what would be required in a Java source file context.

Comment by Przemyslaw Bielicki [ 10/Oct/13 ]

Yes I know this but it's not what is needed here.

What if one of my customers needs CALCULATOR_INPUT and another one CalculatorInput as root XML element? Should I maintain two different versions of class CalculatorInput.java with different annotations?

This is not a imaginary requirement - we have it in production.

It's not an acceptable solution.
Please take a look at my patch. I fixed it in an elegant way.

Cheers,
Przemyslaw

Comment by Przemyslaw Bielicki [ 10/Oct/13 ]

@Iaune - yes I have the fix

Comment by Przemyslaw Bielicki [ 10/Oct/13 ]

@Iaroslav - could you please reopen this issue. It's perfectly valid.

Thanks

Comment by Przemyslaw Bielicki [ 01/Apr/14 ]

patch available on github: https://github.com/pbielicki/jaxb/commit/25a20c8a88bdc7eea83f2ccefffc6347bd6abc34





[JAXB-980] Unable to set a generic factory method for @XmlType - factoryMethod / factoryClass Created: 04/Oct/13  Updated: 01/Apr/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Przemyslaw Bielicki Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JAXB implementation does not allow a generic factory method. Let's take a look at this simple example:

CalculatorInput.java
import javax.inject.Inject;
import javax.inject.Named;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

@XmlRootElement(name = "CalculatorInput")
@XmlType(factoryMethod = "getBean", factoryClass = BeanFactory.class)
@Named
public class CalculatorInput {
  
  @Inject
  Context someContext;
IocContainerObjectFactory .java
import javax.inject.Named;
import javax.inject.Singleton;

@Named
@Singleton
public class IocContainerObjectFactory {

  // bean factory init omitted 

  public static <T> T getBean(Class<T> clazz) {
    return beanFactory.getBean(clazz);
  }
}

Example provided above is impossible to implement in current JAXB. The problem here is that you either let JAXB invoke no-arg constructor of CalculatorInput class or explicit static factory method inside this class or in specific factory class. Note that you must have one factory method per class which is extremely bulky, not object-oriented, boilerplate, blah blah blah. Basically it's a mistake.
I know better than JXAB how to create my objects - I need JAXB only to fill these beans with parsed XML content.

Another argument is that JAXB in the current state completely ignores existence of Dependency Injection (which is a part of Java EE specification). In case JAXB creates my CalculatorInput, someContext attribute will be ignored (thus null) by DI container as it has absolutely no knowledge on this instance. The only correct way to make the injection work is to obtain the new instance from the DI bean / object factory - see IocContainerObjectFactory. OK, it is possible but only in such form (again, bulky, boilerplate, ugly):

IocContainerObjectFactory .java
import javax.inject.Named;
import javax.inject.Singleton;

@Named
@Singleton
public class IocContainerObjectFactory {

  // bean factory init omitted 

  public static CalculatorInput getCalculatorInput() {
    return beanFactory.getBean(CalculatorInput.class);
  }

  public static CurrencyConverterInput getCurrencyConverterInput() {
    return beanFactory.getBean(CurrencyConverterInput.class);
  }

  // etc.

}

Imagine what happens if you have more than couple of beans...

Note on JSR-222 specification

JavaDoc of javax.xml.bind.annotation.XmlType says:

XmlType.java
/**
 * Name of a no-arg factory method in the class specified in <tt>factoryClass</tt> factoryClass(). 
 * 
 */
String factoryMethod() default "";

But, the JSR-222 specification does not explicitly say that it must be a no-arg factory method.

Please correct me if I'm wrong.



 Comments   
Comment by Przemyslaw Bielicki [ 04/Oct/13 ]

how can I upload a patch file? I fixed this problem and I would like to submit my proposal

Comment by Przemyslaw Bielicki [ 04/Oct/13 ]

I sent my patch to dev@jaxb.java.net

Cheers,
Przemek

Comment by Przemyslaw Bielicki [ 01/Apr/14 ]

Patch available on GitHub: https://github.com/pbielicki/jaxb/commit/c70183967936ed3e3b0be46eb65694e95c4d583c





[JAXB-1009] JAXB spec should be updated to support new JDK8 Date/Time apis Created: 01/Apr/14  Updated: 01/Apr/14

Status: Open
Project: jaxb
Component/s: spec
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Martin Grebac Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JAXB-793] Multiple element definition not read correctly Created: 06/Nov/10  Updated: 28/Mar/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: fhuonder Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 793
Tags: metro2_1-waived, metro2_2-waived, metro2_3-waived

 Description   

Hi all,

I have the following schema complex type:

<complexType name="PolicyType">
<complexContent>
<restriction base="

{http://www.w3.org/2001/XMLSchema}

anyType">
<sequence>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

Description" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

PolicyDefaults" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

CombinerParameters" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

Target"/>
<choice maxOccurs="unbounded">
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

CombinerParameters" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

RuleCombinerParameters" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

VariableDefinition"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

Rule"/>
</choice>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

Obligations" minOccurs="0"/>
</sequence>
<attribute name="PolicyId" use="required" type="

{http://www.w3.org/2001/XMLSchema}

anyURI" />
<attribute name="Version" type="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

VersionType" default="1.0" />
<attribute name="RuleCombiningAlgId" use="required" type="

{http://www.w3.org/2001/XMLSchema}

anyURI" />
</restriction>
</complexContent>
</complexType>

The corresponding JAXB class looks like:

@XmlType(name = "PolicyType", propOrder =

{ "description", "policyDefaults", "combinerParameters", "target", "additionalInformation", "obligations" }

)
public class PolicyType implements Evaluatable, Serializable {
private static final long serialVersionUID = 1L;
@XmlElement(name = "Description")
private String description;
@XmlElement(name = "PolicyDefaults")
private DefaultsType policyDefaults;
@XmlElement(name = "combinerParameters")
private CombinerParametersType combinerParameters;
@XmlElement(name = "Target", required = true)
private TargetType target;
@XmlElements(

{ @XmlElement(name = "Rule", type = RuleType.class), @XmlElement(name = "VariableDefinition", type = VariableDefinitionType.class), @XmlElement(name = "RuleCombinerParameters", type = RuleCombinerParametersType.class), @XmlElement(name = "CombinerParameters", type = CombinerParametersType.class) }

)
private List<Object> additionalInformation;
@XmlElement(name = "Obligations")
private ObligationsType obligations;
@XmlAttribute(name = "PolicyId", required = true)
@XmlSchemaType(name = "anyURI")
private String policyId;
@XmlAttribute(name = "Version")
private String version;
@XmlAttribute(name = "RuleCombiningAlgId", required = true)
@XmlJavaTypeAdapter(RuleCombiningAlgorithmJAXBTypeAdapter.class)
@XmlSchemaType(name = "anyURI")
private AbstractRuleCombiningAlgorithm ruleCombiningAlg;

...

The thing I want to talk about is the CombinerParameters element. This element is defined twice at different places.
Now when I unmarshal an XML that contains two CombinerParameters elements at the two places the unmarshalling is incorrect.
The second CombinerParameters element is saved into the CombinerParameters element and the first one disappears.
I think the unmarshalling saves both elements into this element and the second overrides the first.
I think the behavior should be that the first is saved into the CombinerParameters field and the second into the
additionalInformation (Choice).



 Comments   
Comment by Pavel Bucek [ 19/Nov/10 ]

thanks for reporting; too late for 2.2.2

metro2.1-waived

Comment by daveboden [ 18/Dec/12 ]

I'm seeing a very similar, if not identical, issue with the FPML 5.4 schema. Please note that I'm using the latest (at time of writing) version of jaxb-impl, 2.2.7-b41, both to compile the bindings and at runtime. Here's the relevant extract from fpml-doc-5.4.xsd :

<xsd:complexType name="TradeIdentifier">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
    A type defining a trade identifier issued
    by the indicated party.
    </xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
    <xsd:choice>
      <xsd:sequence>
        <xsd:element name="issuer" type="IssuerId"></xsd:element>
        <xsd:element name="tradeId" type="TradeId"></xsd:element>
      </xsd:sequence>
      <xsd:sequence>
        <xsd:group ref="PartyAndAccountReferences.model">
          <xsd:annotation>
            <xsd:documentation xml:lang="en">
            A pointer style reference to a party identifier and optionally
            an account identifier defined elsewhere in the document.
            The party referenced has allocated the trade identifier.
            </xsd:documentation>
          </xsd:annotation>
        </xsd:group>
        <xsd:choice maxOccurs="unbounded">
          <xsd:element name="tradeId" type="TradeId"></xsd:element>
          <xsd:element name="versionedTradeId" type="VersionedTradeId">
            <xsd:annotation>
              <xsd:documentation xml:lang="en">
              A trade identifier accompanied by a version number.
              In regulatory reporting views, this should be avoided
              except for internal mnessaging.
              </xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:sequence>
    </xsd:choice>
  </xsd:sequence>
  <xsd:attribute name="id" type="xsd:ID" />
</xsd:complexType>

There are essentially two totally separate definitions of elements that have the same name. <tradeId/>. However, when JAXB parses the corresponding XML it treats all <tradeId/> values as they're the first definition. This results in multiple <tradeId/> values that are part of the second definition (that allows multiple instances of the element) being overwritten as the attribute. The JAXB parse loses the values of all but the last element in the incoming XML.

In this example, <partyTradeIdentifier> is of type TradeIdentifier (well, actually it's a subclass called PartyTradeIdentifier but that is not relevant at this stage):

<tradeReferenceInformation>
    <partyTradeIdentifier>
        <partyReference href="MSERV_BANK123"/>
        <tradeId tradeIdScheme="TradeRefNbr">1212H88885</tradeId>
        <tradeId tradeIdScheme="MatchID">MSE21212.026</tradeId>
        <tradeId tradeIdScheme="ClearerID">667789</tradeId>
    </partyTradeIdentifier>
    <partyTradeIdentifier>
        <issuer issuerIdScheme="http://www.fpml.org/coding-scheme/external/cftc/issuer-identifier">178921368077</issuer>
        <tradeId tradeIdScheme="http://www.fpml.org/coding-scheme/external/unique-transaction-identifier">AAB152121</tradeId>
    </partyTradeIdentifier>
</tradeReferenceInformation>

The result of the JAXB parse is two TradeIdentifier beans. The second one has the tradeId correctly filled in as "AAB152121". Unfortunately the first one doesn't have all 3 values in a list, it just retains the "667789" 3rd and final value as the tradeId. The object that represents the choice maxOccurs="unbounded", which is List<Object> getTradeIdOrVersionedTradeId contains NULL.

I'll work on a simplified test case.

Comment by daveboden [ 07/Jan/13 ]

By the time the Unmarshaller is using a SAX parser to look at the <tradeId/> element, the handler has a map keyed on XML tag Name (namespace + element name) to use:

StructureLoader.childElement(UnmarshallingContext$State, TagName) line: 248
ChildLoader child = childUnmarshallers.get(arg.uri,arg.local);

This only contains a single entry for <tradeId/>

The map is built up when the JAXB context is created here:

SingleElementLeafProperty.buildChildElementUnmarshallers line: 191
handlers.put(tagName, new ChildLoader(l, null));

This overwrites one tag name with another without warning. This line of code should probably check for the existence of the key in the map before overwriting it and at least log something at WARN level.

I don't have any ideas at the moment on how to make an improvement to rectify this issue. Because it's a SAX parser (rather than a more complex grammar parser) and everything is keyed just tag Name, it's not going to be a small change. I'll post my test case and workaround.

Comment by Iaroslav Savytskyi [ 08/Jan/13 ]

Nice, thanks a lot.

Comment by kelvin-low [ 28/Mar/14 ]

I having this issue as well. Daveboden, are you able to provide a workaround?





[JAXB-1008] Misleading xjc Error Message Created: 27/Mar/14  Updated: 27/Mar/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: WizardOfZot Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using xjc against a schema file that specifies an invalid version for the xmlns jaxb version results in the following error message:
[ERROR] JAXB version attribute must be "1.0"

However, other versions are applicable such as 2.0 and 2.1

Example:

Schema with the following root element declarations:
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
jaxb:version="2.2"






[JAXB-1007] NPE from marshalling an IDREF that point to a missing ID attribute value Created: 20/Mar/14  Updated: 20/Mar/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: tuomas_kiviaho Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

NPE is thrown prematurely in case of an id attribute being null instead of a more appropriate validation event (Object "..." is found in an IDREF property but this object doesnt have an ID.). In order to fix this see AttributeProperty.serializeAttributes method that deals with the null correctly.

It seems that other people have had to deal this problem before (http://stackoverflow.com/questions/10705532/in-jaxb-marshalling-how-to-identify-which-child-element-caused-jaxb-marshallin). I guess that pinpointing of the cause can be quite problematic with the current behavior.

  • * StackTrace * *
    AttributeProperty<BeanT>.getIdValue(BeanT) line: 128
    ClassBeanInfoImpl<BeanT>.getId(BeanT, XMLSerializer) line: 322
    TransducedAccessor$IDREFTransducedAccessorImpl<BeanT,TargetT>.print(BeanT) line: 290
    TransducedAccessor$IDREFTransducedAccessorImpl<BeanT,TargetT>(DefaultTransducedAccessor<T>).writeLeafElement(XMLSerializer, Name, T, String) line: 69
    SingleElementLeafProperty<BeanT>.serializeBody(BeanT, XMLSerializer, Object) line: 130
    ClassBeanInfoImpl<BeanT>.serializeBody(BeanT, XMLSerializer) line: 361
    XMLSerializer.childAsXsiType(Object, String, JaxBeanInfo, boolean) line: 696





[JAXB-1006] Add @XmlSchemaType(name = "dateTime|date|time|...") annotation Created: 14/Mar/14  Updated: 14/Mar/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Michael Osipov Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

XJC does not add @XmlSchemaType(name = "dateTime|date|time|...") annotation on a XMLGregorianCalendar. The result of this is that if JAX-WS uses these classes, the auto-generated schema has xs:anySimpleType instead of the correct type.






[JAXB-1005] Generation of classes with jaxb fails when an element is named "PRN" Created: 11/Mar/14  Updated: 11/Mar/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: francescato Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse Helios, Windows 7



 Description   

I am generating classes from a large xsd file. (Rightclick on pom in projectexplorer, run-as "maven generate sources") When I name an Element with "PRN" the generation process get stuck. It do not break and get also not to finished.
When I rename the Element to PRN2 the same code works.
Environment Helios, java 7, maven, maven-jaxb2 plugin 0.8.0 with basics and annotate 0.6.2. Jaxb version 2.2.7 (also tried 2.2.8 and 2.2.0 ...)
Cant explain such a strange behavior, where the name of an element makes the generation to be stuck.

Extraction from pom.xml
<build>
<plugins>
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.8.0</version>
<configuration>
<schemaDirectory>src/main/resources</schemaDirectory>
<bindingDirectory>src/main/resources</bindingDirectory>
<generatePackage>migration.xml</generatePackage>
<strict>true</strict>
<extension>true</extension>
<forceRegenerate>true</forceRegenerate>
<generateDirectory>src/main/java</generateDirectory>
<!-- <readOnly>true</readOnly> -->
<verbose>true</verbose>

<plugins>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics</artifactId>
<version>0.6.2</version>
</plugin>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics-annotate</artifactId>
<version>0.6.2</version>
</plugin>
</plugins>
<args>
<arg>-Xannotate</arg>
<!-- <arg>-XtoString</arg> -->
</args>
</configuration>
<executions>
<execution>
<id>generate-sources</id>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>

<!-- plugin to add the jars to the generated jar. -->
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>src/assemble/exe.xml</descriptor>
</descriptors>
<archive>
<manifestFile>src/main/java/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
</plugins>
</build>

The XSD fragment which do not work.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="PRN">
<xs:annotation>
<xs:documentation xml:lang="en">
ProductRelation
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="A" use="required">
<xs:annotation>
<xs:documentation xml:lang="en">
ProductIdRef
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:IDREF">
<xs:minLength value="4"/>
<xs:maxLength value="14"/>
<xs:pattern value="(PDT|PDT-)([0-9])+"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="B" use="required">
<xs:annotation>
<xs:documentation xml:lang="en">
AmountValue
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:long">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="2147483647"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>






[JAXB-992] Property "Value" is already defined in /com/sun/xml/xsom/impl/parser/datatypes.xsd[14,33] Created: 29/Nov/13  Updated: 26/Feb/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.1.13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: martinspamer Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 + Java 1.7.45 + Maven 3.11 + Eclipse Kepler



 Description   

Attempting to compile a schema exposes duplicate propertty in datatypes.xsd

[ERROR] jar:file:/C:/Users/MSpamer/.m2/repository/com/sun/xml/bind/jaxb-xjc/2.1.13/jaxb-xjc-2.1.13.jar!/com/sun/xml/xsom/impl/parser/datatypes.xsd[14,33]
com.sun.istack.SAXParseException2; systemId: jar:file:/C:/Users/MSpamer/.m2/repository/com/sun/xml/bind/jaxb-xjc/2.1.13/jaxb-xjc-2.1.13.jar!/com/sun/xml/xsom/impl/parser/datatypes.xsd; lineNumber: 14; columnNumber: 33; Property "Value" is already defined. Use <jaxb:property> to resolve this conflict.
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:82)
at com.sun.tools.xjc.reader.ModelChecker.checkPropertyCollision(ModelChecker.java:108)
at com.sun.tools.xjc.reader.ModelChecker.check(ModelChecker.java:94)
at com.sun.tools.xjc.reader.ModelChecker.check(ModelChecker.java:67)
at com.sun.tools.xjc.reader.xmlschema.BGMBuilder._build(BGMBuilder.java:189)
at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.build(BGMBuilder.java:116)
at com.sun.tools.xjc.ModelLoader.annotateXMLSchema(ModelLoader.java:415)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:167)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:113)
at com.sun.tools.xjc.Driver.run(Driver.java:313)
at org.codehaus.mojo.jaxb2.AbstractXjcMojo.execute(AbstractXjcMojo.java:327)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
at org.codehaus.classworlds.Launcher.main(Launcher.java:46)



 Comments   
Comment by Iaroslav Savytskyi [ 02/Dec/13 ]

Hi,

Please provide more info:

1) What exactly are you trying to do?
2) Why are you using JAXB 2.1.x?

Thanks.

Comment by martinspamer [ 09/Jan/14 ]

I'm writing an automation test suite for a system that has a unrigourously defined schema from a third party over which I have no control.

I was using http://mojo.codehaus.org/jaxb2-maven-plugin/ because I wanted to utilise its feature for creating test classes for the element object model. That plugin uses 2.1.13.

Comment by Iaroslav Savytskyi [ 09/Jan/14 ]

Can you please send me testcase to iaroslav.savytskyi at oracle.com so I will attach it here.

Thanks.

Hopefully we will update maven plugin for JAXB-RI soon.

Comment by anupamb82 [ 26/Feb/14 ]

I also faced the same issue when I tried to generate the class out of this xsd file.

ftp://ftp.ncbi.nlm.nih.gov/pubchem/data_spec/pubchem.xsd

I hope this will help to resolve the problem.

Regards
Anupam





[JAXB-936] problem with XMLMixed in a tag annotated XmlAnyElement Created: 21/Dec/12  Updated: 18/Feb/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: beynet Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If two tags are separated only by spaces these spaces are lost.
Xml Example :
------------
<testAny> <h> <body>
<p>
Text content
<a href="http://www.google.com">link2</a> <a href="http://www.google.com">link3</a>
.
</p>
</body>
</h>
</testAny>

Java Jaxb class :
-------------
@XmlType(name="TestAnyType")
@XmlRootElement(name="testAny")
public class TestAny {
@XmlAnyElement(lax=false)
@XmlMixed
public List<Object> getContent()

{ return(content); }

private List<Object> content = new ArrayList<Object>();
}

Code to produce the problem :
--------------------------
public class TestAnyT {
@Test
public void marshal() throws JAXBException

{ JAXBContext context = JAXBContext.newInstance(TestAny.class); System.out.println(context); Marshaller marshaller = context.createMarshaller(); Unmarshaller unmarshaller = context.createUnmarshaller(); TestAny t = (TestAny)unmarshaller.unmarshal(new File("./src/test/java/org/beynet/t.xml")); System.out.println(t); marshaller.marshal(t, new StreamResult(System.out)); }

}
Resulting XML after marshaling :
---------------------------
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><testAny> <h><body><p>
Text content
<a href="http://www.google.com">link2</a><a href="http://www.google.com">link3</a>
.
</p>
</body>
</h>
</testAny>

The spaces between the two tags "<a" are lost ....



 Comments   
Comment by gastush [ 18/Feb/14 ]

The characters that are "lost" are the spaces but also the Line feed and tabs (all chars in the space class of characters).
This is causing any issue when using JAXB with XML fragment (using xsd:any) that are supposed to be in a cannonicalized form. (think about a WebService, using JAX-WS for which one of the operations takes an xsd:any that is in a cannonicalized form at that should be used to compute or verify a signature).
Adding any non-space chars between the tags brings back all the space characters in the marshalled XML.

If it can help, looking at the org.w3c.dom.Node produced when unmarshalling, one can see that the spaces that are lost are present in the previousSibling elements only.





[JAXB-924] bindingschema_2_0.xsd: globalBindings: extension binding declarations: wrong mulitplicity Created: 16/Oct/12  Updated: 13/Feb/14

Status: Open
Project: jaxb
Component/s: spec
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: puce Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 11
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following JAXB bindings file creates the Adapter classes as expected, but Eclipse and XMLSpy say it's no valid:

<?xml version="1.0" encoding="UTF-8"?>
<jxb:bindings xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jxb="http://java.sun.com/xml/ns/jaxb" xsi:schemaLocation="http://java.sun.com/xml/ns/jaxb http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd" version="2.1">
<jxb:globalBindings>
<jxb:javaType name="java.util.Calendar" xmlType="xs:date" parseMethod="javax.xml.bind.DatatypeConverter.parseDate" printMethod="javax.xml.bind.DatatypeConverter.printDate" />
<jxb:javaType name="java.util.Calendar" xmlType="xs:dateTime" parseMethod="javax.xml.bind.DatatypeConverter.parseDateTime" printMethod="javax.xml.bind.DatatypeConverter.printDateTime" />
<jxb:javaType name="java.util.Calendar" xmlType="xs:time" parseMethod="javax.xml.bind.DatatypeConverter.parseTime" printMethod="javax.xml.bind.DatatypeConverter.printTime" />
</jxb:globalBindings>
</jxb:bindings>

The error is something like:

cvc-complex-type.2.4.b: The content of element 'jxb:globalBindings' is not complete. One of '

{"http://java.sun.com/xml/ns/jaxb":javaType, "http://java.sun.com/xml/ns/jaxb":serializable, WC[##other:"http://java.sun.com/xml/ns/jaxb"]}

' is expected.

I was pointed out that the multiplicity should be as follows:

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>allows extension binding declarations to be specified.</xs:documentation>
</xs:annotation>
</xs:any>



 Comments   
Comment by gzress [ 03/Jan/13 ]

Wouldn't it be a little faster to correct the XSD than to change this issue priority?

regards
Grzegorz Grzybek

Comment by Martin Grebac [ 03/Jan/13 ]

Well, not - the schema is defined in the JSR 222 spec, so this can only be addressed within MR.

Comment by gzress [ 03/Jan/13 ]

Well, right... And how to get the MR to be released?

Comment by puce [ 15/Oct/13 ]

Any news on this?

Comment by puce [ 13/Feb/14 ]

Will this be fixed in Java 8?

Comment by Iaroslav Savytskyi [ 13/Feb/14 ]

I'm not aware about the coming MR. So, unfortunately, no news and I don't think this would be fixed in JDK8.





[JAXB-999] Not well-formed XML output by Marshaller in conjunction with @XmlAnyAttribute Created: 26/Jan/14  Updated: 04/Feb/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: m4t Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Max OS X, JDK 1.7.0_51


Tags: marshaller, well-formed, xmlanyattribute

 Description   

Summary

I encountered a situation where a javax.xml.bind.Marshaller produces not well-formed XML, despite throwing no exception nor raising a validation event. The problem arises when using @XmlAnyAttribute-Annotation in a special way.

Details

Consider the following scenario (imports omitted):

Test.java
@XmlAccessorType(XmlAccessType.NONE)
@XmlRootElement
public class Test {
	
	@XmlAttribute
	public String id;
	
	@XmlAnyAttribute
	public Map<QName,String> other;

}
test.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >
    <xs:element name="test">
    	<xs:complexType>
    		<xs:anyAttribute processContents="skip"/>
    	</xs:complexType>
    </xs:element>
</xs:schema>
Main.java
public class Main {

	public static void main(String[] args) throws Exception {

		Test t = new Test();
		t.id = "5";
		t.other = new HashMap<QName, String>();
		t.other.put(new QName("id"), "10");

		JAXBContext jc = JAXBContext.newInstance(Test.class);
		Marshaller m = jc.createMarshaller();
		SchemaFactory sf = SchemaFactory
				.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
		Schema schema = sf.newSchema(new File("test.xsd"));
		m.setSchema(schema);
		m.setProperty(Marshaller.JAXB_NO_NAMESPACE_SCHEMA_LOCATION, "test.xsd");
		m.setEventHandler(new ValidationEventHandler() {

			@Override
			public boolean handleEvent(ValidationEvent event) {
				System.out.println("Validaten event received.");
				return false;
			}
		});
		m.marshal(t, new File("test.xml"));

	}

}

The invocation of Main.main does the following:

  • No exception is raised.
  • The handleEvent-method is not called.
  • A file "test.xml" is written, in which the element "test" carries the attribute "id" twice. Once with value "5", and once with value "10". Hence, it is not well-formed XML.

Since the operation silently succeeds, a user expects a valid XML with respect to the XML schema. As far as I know, validity w.r.t. schema implies that it is also well-formed. Assuming no schema is used, a user would expect that the output is well-formed if no error or warning is given.

The ugly workaround is to add an additional check on top of the Marshal validation for well-formedness, as long as this shortcoming exists.

Side-notes

I am aware of the fact that this usage of the XmlAnyAttribute-map can be considered as an edge case. Nevertheless, the Marshaller should check for validity of the input. At the moment, the silent-fail-outcome is highly undesirable.

Proposals

Proposals in which direction a fix could go:

  1. A Marshaller raises an exception if the output would not be well-formed XML. The postcondition, that the output is always well-formed, should be included in the javadocs.
    1. In the special case where a regularly mapped attribute is again specified in the XmlAnyAttribute-map, this error is explained in the exception.
  2. If proposal 1 can not be implemented: When using a XML schema on a Marshaller, the validation succeeds only if the XML is also well-formed.

Thanks for looking into this!



 Comments   
Comment by m4t [ 04/Feb/14 ]

A situation where also not well-formed XML is produced, but doesn't build on attribute collision, is the following:

If you store an attribute with empty name into the QName-map. Replace

new QName("id")

with

new QName("")

in the above example. No exception is raised, the produced string is not XML (attribute with empty name). I guess also invalid characters for XML would not be intercepted.





[JAXB-1002] "com.mypackage.A" is substituting "com.mypackage.BaseType", but "com.mypackage.A" is bound to an anonymous type. Created: 28/Jan/14  Updated: 28/Jan/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.4u2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: MRalwasser Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows



 Description   

I am facing an issue while marshalling a JAXB model tree to a xml file using JAXB.

Its classes has been created by the JDK's xjc.
The xml schema files seem to be valid according xjc (and other xml tools).
The creation of the class files completed without any errors.

However, I am unable to marshall them, the exception which I get is:

com.sun.istack.internal.SAXException2: "com.mypackage.A" is substituting "com.mypackage.BaseType", but "com.mypackage.A" is bound to an anonymous type.
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:237)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:652)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayElementNodeProperty.serializeItem(ArrayElementNodeProperty.java:54)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayElementProperty.serializeListBody(ArrayElementProperty.java:157)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayERProperty.serializeBody(ArrayERProperty.java:144)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:335)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:335)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:146)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:116)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:318)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:325)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:61)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayReferenceNodeProperty.serializeListBody(ArrayReferenceNodeProperty.java:103)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayERProperty.serializeBody(ArrayERProperty.java:144)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayElementNodeProperty.serializeItem(ArrayElementNodeProperty.java:54)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayElementProperty.serializeListBody(ArrayElementProperty.java:157)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayERProperty.serializeBody(ArrayERProperty.java:144)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:141)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:116)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:318)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:325)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:61)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:483)
at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:308)
at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:236)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)
(...)

I am asking whether

  • if this is a jaxb bug
  • I am doing something wrong
  • if the schema files are somewhat errornous which xjc does not detect

Important:
I cannot modify the XSD files - they are defined by federal authorities and according to several xml/xsd tools they seem to be correct.






[JAXB-998] running with option -fullversion fails Created: 22/Jan/14  Updated: 22/Jan/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jkidd Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac Mavericks


Tags: cli, command, command-line

 Description   

jenss-mbp:bin jkv$ ./xjc.sh -fullversion
Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: build.number
at java.text.MessageFormat.makeFormat(MessageFormat.java:1420)
at java.text.MessageFormat.applyPattern(MessageFormat.java:479)
at java.text.MessageFormat.<init>(MessageFormat.java:363)
at java.text.MessageFormat.format(MessageFormat.java:835)
at com.sun.tools.xjc.Messages.format(Messages.java:54)
at com.sun.tools.xjc.Driver.run(Driver.java:232)
at com.sun.tools.xjc.Driver.run(Driver.java:200)
at com.sun.tools.xjc.Driver._main(Driver.java:123)
at com.sun.tools.xjc.Driver.access$000(Driver.java:80)
at com.sun.tools.xjc.Driver$1.run(Driver.java:103)
Caused by: java.lang.NumberFormatException: For input string: "build.number"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:492)
at java.lang.Integer.parseInt(Integer.java:527)
at java.text.MessageFormat.makeFormat(MessageFormat.java:1418)
... 9 more






[JAXB-970] JAXB marshal if identation exceeds nested level 8 Created: 25/Jul/13  Updated: 09/Jan/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1.10, 2.2.4u2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: matejsp Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour
Environment:

JDK 1.6 and JDK 1.7



 Description   

When calling JAXB marshal with pretty print it outputs:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<a>
<b>
<c>
<d>
<e>
<f>
<g>
<h>
<i>
<j/>
</i>
</h>
</g>
</f>
</e>
</d>
</c>
</b>
</a>

The problem is when reaching indentation level 8 it restarts indentation.

The problem is in the:
IndentingUTF8XmlOutput.java

buggy function:
private void printIndent() throws IOException

{ write('\n'); int i = depth%8; write( indent8.buf, 0, i*unitLen ); i>>=3; // really i /= 8; for( ; i>0; i-- ) indent8.write(this); }

You can see that variable i is using remainder of division with 8.
After that i>>3 is already the remainder.
i >>= 3 (i = i >> 3) should be instead ... i = depth >> 3;

Other implementations does not exhibit such behavior.



 Comments   
Comment by matejsp [ 24/Dec/13 ]

There is another issue in Encoding class.
indent8.write(this); does not work as it should.

code
Encoded e = new Encoded(indentStr);
indent8 = new Encoded();
indent8.ensureSize(e.len*8);
unitLen = e.len;
for( int i=0; i<8; i++ )
System.arraycopy(e.buf, 0, indent8.buf, unitLen*i, unitLen);
code

The problem is that Encoded.ensureSize does not change the field of encoded length.

Comment by Iaroslav Savytskyi [ 09/Jan/14 ]

I agree with you.. It's strange.
But I also see good thing and may be this code was written to do exactly this.

Imagine 100x elements depth. Is it good idea to scroll to see the middle element???

We will discuss this internally.

Thanks a lot for reporting.

Comment by laune [ 09/Jan/14 ]

Also, consider the potentially huge amount of white space.





[JAXB-994] Support for XML Schema 1.1 Created: 16/Dec/13  Updated: 16/Dec/13

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: frocar Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Support for XML Schema 1.1 would be awesome.
Especially things like assertions, conditional includes.






[JAXB-993] Proporder doesn't recogonize property if it is inherited Created: 10/Dec/13  Updated: 10/Dec/13

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kavai Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu, jdk1.6.0_45



 Description   

Whenever I inherit a property from a base-class, propOrder doesn't recognize it, and throws an exception:

Exception in thread "main" com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
Property traceId appears in @XmlType.propOrder, but no such property exists.
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:106)
...

Example to reproduce:
----------------------PropOrderDemo.java---------------------------------
public class PropOrderDemo
{
public static void main(String[] args) throws Exception

{ javax.xml.bind.JAXBContext jaxbContext = javax.xml.bind.JAXBContext.newInstance(FaultObject.class); javax.xml.bind.Marshaller marshaller = jaxbContext.createMarshaller(); FaultObject exception = new FaultObject(13); marshaller.marshal(exception, System.out); }

}

----------------------FaultObject.java---------------------------------

@javax.xml.bind.annotation.XmlType(propOrder =

{ "traceId" }

)
@javax.xml.bind.annotation.XmlRootElement
@javax.xml.bind.annotation.XmlAccessorType(javax.xml.bind.annotation.XmlAccessType.PROPERTY)
public class FaultObject extends AbstractTraceableObject
{
private int traceId;

public FaultObject()
{
}

public FaultObject(int traceId)

{ this.traceId = traceId; }

@Override public int getTraceId()
{ return this.traceId; }

@Override public void setTraceId(int traceId)
{ this.traceId = traceId; }

}

--------------------------AbstractTraceableObject.java--------------------------------------
public class AbstractTraceableObject
{
public int getTraceId()

{ return 0; }

public void setTraceId(int traceId)
{
}
}






[JAXB-991] Handle loading errors of XJC plugins gracefully to ignore dependencies from unnecessary plugins Created: 29/Nov/13  Updated: 29/Nov/13

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: hdelfs Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When loading additional XJC plugins with the service discovery mechanism, java.util.ServiceLoader throws a ServiceConfigurationError (introduced in Java 6) if a plugin class cannot be loaded or instantiated. I suggest to output a warning in this case and continue the discovery process with further plugins.

Also consider the remark from the ServerceLoader's iterator() Javadoc description:

To write robust code it is only necessary to catch ServiceConfigurationError when using a service iterator.

In my case I wanted to use the ToString plugin from JAXB2 Basics, which is bundled with other plugins. Of these namely the Inheritance plugin requires the JavParser library as dependency. Currently I have to include the library in my classpath (though I don't use it) just to avoid the following Error:

java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: Provider 
org.jvnet.jaxb2_commons.plugin.inheritance.InheritancePlugin could not be instantiated: 
java.lang.NoClassDefFoundError: japa/parser/ParseException
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:116)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at org.apache.tools.ant.Target.execute(Target.java:390)
	at org.apache.tools.ant.Target.performTasks(Target.java:411)
	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
	at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
	at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
	at org.eclipse.ant.internal.launching.remote.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32)
	at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
	at org.eclipse.ant.internal.launching.remote.InternalAntRunner.run(InternalAntRunner.java:423)
	at org.eclipse.ant.internal.launching.remote.InternalAntRunner.main(InternalAntRunner.java:137)
Caused by: java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: Provider 
org.jvnet.jaxb2_commons.plugin.inheritance.InheritancePlugin could not be instantiated: 
java.lang.NoClassDefFoundError: japa/parser/ParseException
	at java.util.ServiceLoader.fail(ServiceLoader.java:207)
	at java.util.ServiceLoader.access$100(ServiceLoader.java:164)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
	at com.sun.tools.xjc.Options.findServices(Options.java:957)
	at com.sun.tools.xjc.Options.getAllPlugins(Options.java:374)
	at com.sun.tools.xjc.Options.parseArgument(Options.java:688)
	at com.sun.tools.xjc.Options.parseArguments(Options.java:809)
	at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:474)
	at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:457)
	at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:380)
	at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:103)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	... 10 more
Caused by: java.lang.NoClassDefFoundError: japa/parser/ParseException
	at org.jvnet.jaxb2_commons.plugin.inheritance.InheritancePlugin.<init>(InheritancePlugin.java:219)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at java.lang.Class.newInstance0(Class.java:355)
	at java.lang.Class.newInstance(Class.java:308)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345)
	... 25 more
Caused by: java.lang.ClassNotFoundException: japa.parser.ParseException
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 33 more





[JAXB-989] Java's JAXB implementation does not handle underscores properly Created: 26/Nov/13  Updated: 26/Nov/13

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: prmatta Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Tags: java, jaxb, jaxb-xjc, jersey

 Description   

The usecase to recreate the issue is to try and translate the following schema to java:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="Foo_Bar">
<xs:sequence>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="choices" type="TypeMyEnum" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="TypeMyEnum">
<xs:restriction base="xs:string">
<xs:enumeration value="ALPHA_1_0_0"/>
<xs:enumeration value="BETA_2_0_0"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

By default, xjc will create a file called FooBar.java and a file called TypeMyEnum.java. Notice how xjc "ate" the underscore in Foo_Bar. Also, by default, the internals of TypeMyEnum look like this:

ALPHA_1_0_0,
BETA_2_0_0;

To get the underscore back in Foo_Bar, one has to use a bindings file as follows:

<jxb:bindings version="1.0"
xmlns:jxb="http://java.sun.com/xml/ns/jaxb">
<jxb:globalBindings underscoreBinding="asCharInWord"/>
</jxb:bindings>

Now, the code generates a Foo_Bar.java file as desired but horribly changes the internals of TypeMyEnum to look like:

@XmlEnumValue("ALPHA_1_0_0")
ALPHA__1_0__0("ALPHA_1_0_0"),

@XmlEnumValue("BETA_2_0_0")
BETA__2_0__0("BETA_2_0_0");
private final String value;

It seems every underscore in an enum value is changed to three underscores. This is the issue. This is easily reproducible and beyond me why xjc would do this.

There is no known way to get xjc to retain the underscore in the class name (i.e Foo_Bar.java) AND generate a sane enum file.






[JAXB-988] Add a new command line option to xjc for activating @XmlElementWrapper Created: 06/Nov/13  Updated: 06/Nov/13

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Improvement Priority: Trivial
Reporter: yossico Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A


Tags: optimization, xjc

 Description   

Currently xjc creates a wrapper class as a container for a collection. This generates verbose code that is quite difficult to use.
The new CLI option will eliminate these wrapper classes and instead will make use of @XmlElementWrapper.
There are some implementations out there for doing this kind of optimization (e.g., https://github.com/dmak/jaxb-xew-plugin) but it seems much more natural for xjc to support it.






[JAXB-987] nillable elements with required attributes Created: 24/Oct/13  Updated: 24/Oct/13

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dlatt Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Unfortunately I need to bring this issue up again since I'm again bitten by this bug (See JAXB-822, which I strongly suggest to re-open, but I'm not allowed to do so).

A nillable element with element content and required attributes cannot be processed using JAXB, since XJC doesn't create an JAXBElement wrapper.

It's occuring for example in the official German federal standard XJustiz set of XML schemas which we are obliged to use.

If this bug cannot be fixed, would you please care to explain a bit longer than the short comment by M. Grebac in JAXB-822 on 2011-Nov-22? As I wrote in the follow-up comment (which a developer might not have read as the issue was already closed then), that "solution" is not very helpful if one is forced to support a given schema.

Right now, our solution is to generate the code once every time there is an update on the schema and then, by hand, look for all instances where an JAXBElement wrapper is needed, modifying the generated code. This is a very frustrating task.

Please see also https://issues.apache.org/jira/browse/CXF-3732






[JAXB-978] UnmarshallerImpl has an ineffective finalize() method Created: 16/Sep/13  Updated: 24/Oct/13

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.4u2, 2.2.5, 2.2.6, 2.2.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: gadavis Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

During upgrading a web service we observed that a the Parallel new garbage collector was unable to achieve the previously seen thoughput when running with JAXB 2.2.5+

On investigation it seems the reason for this is the addition of the `finalize()` method on `UnmarshallerImpl`, this causes the object not to be collected but to be placed to to the finalizer queue. This is problematic for two reasons

  • it increases the contention on the finalizer queue
  • The last unmarshalled object (a large WS response object in our case) is retained until the finalizer invokes the `finalize()` method

In addition, the implementation of the `finalize()` method:

   protected void finalize() throws Throwable {
        try {
            ClassFactory.cleanCache();
        } finally {
            super.finalize();
        }
    }

is broken because the `ClassFactory.cleanCache()` method needs to be called in the same thread as the original use of the `Unmarshaller`, but this won't be true as it will be called the Finalizer thread.

Will be posting a patch to remove the method to the dev mailing list.



 Comments   
Comment by Iaroslav Savytskyi [ 16/Sep/13 ]

Hi,

Thanks for reporting. I'll fix it.

Comment by rshekar [ 23/Oct/13 ]

Hi Iaroslav,

I am seeing a similar issue when using CXF client, 50% of the heap is java.lang.ref.Finalizer objects.

Can you please let me know if the fix planned for a release, and if so any ETA.

Thank you,
Raj.

Comment by Iaroslav Savytskyi [ 24/Oct/13 ]

The problem is that we are not able to determine when we have to clean our cache.

I think we will try to do something with this in 2.2.8... But unfortunately I'm not able to give any estimations when we will start working on this. This year???

Comment by gadavis [ 24/Oct/13 ]

how you clear the cache isn't really important to removing this finalise method. The finalise method does nothing to clear the cache and only messes with the garbage collector.





[JAXB-985] Different marshallization behaviour with OutputStream and Writer Created: 18/Oct/13  Updated: 21/Oct/13

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: glam Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None