[MAVEN2_REPOSITORY-159] Request for org.glassfish.jaxb permission Created: 09/May/13  Updated: 13/May/13  Resolved: 13/May/13

Status: Resolved
Project: maven2-repository
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Iaroslav Savytskyi Assignee: deruelle_jean
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jaxb

 Description   

Hi, I'm the tech lead of JAXB java.net project: http://jaxb.java.net.

We did some changes in our project and planning to push new jaxb artifacts to maven.java.net repository also under "org.glassfish.jaxb" groupId, so please grant me the required permissions. Thank you in advance.



 Comments   
Comment by jorlina [ 13/May/13 ]

– Nexus repository was prepared successfully. –

Configuration has been prepared, now you can:





[JERSEY-1681] Memory Leak in the basic Jersey webapp deploying on GFv312. Created: 29/Jan/13  Updated: 10/Sep/15  Resolved: 26/Feb/13

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: 1.11
Fix Version/s: 1.18, 2.0-rc1, 2.0

Type: Bug Priority: Major
Reporter: gfuser9999 Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours
Original Estimate: 3 hours
Environment:

Platform: GlassFish 3.1.2.2/3.1.2.4
OS: Any OS
Jersey: 1.11.1 --> 1.17 (tested)


Tags: AbstractJAXBProvider, JAXBContextmpl, jaxb, leak, memory, outofmemory, permgen

 Description   

Deploying the simplest Jersey app, running to initialize to get a JAXB
XML resource and undeploying it. Repeating this for a long time
it is seen that GlassFish 3.1.x WebappClassLoader leaks and
eventually gets OutOfMemoryError in PermGen space.

The testcase is just a simple annotated Jersey Demarshaller to XML. (on GFv312 tip)
and whatever Jersey 1.17 (used – including newest Jersey)
It seems that when the JAXBContext is created it is kept in
com.sun.jersey.core.provider.jaxb.AbstractJAXBProvider.jaxbContexts
by the call com.sun.jersey.core.provider.jaxb.AbstractJAXBProvider.getStoredJAXBContext
The jaxbContexts is a WeakHashMap keyed on a "Instance Object" (referrent) created
on the WebappClassLoader and the value is the JAXBContextImpl

It seems to be that the problem in theory with a WeakHashMap if the "Instance Object"
has not strong reference the JAXBContextImpl will automatically be GC.
But this is not the case since JAXBContextImpl itself holds the "Instance Object"
within a collection. This implicitly make this object have a strong reference
from JAXBContextImpl. Due to this the WebappClassLoader is not removed
after a deploy/run/undeploy test.

Side note
-----------
By the way, if bundling Jersey inside the webappp & setting GlassFish
delegate=false classloader option, there is no leak (since the jersey is
local and hence impervious to the issue).



 Comments   
Comment by Jakub Podlesak [ 26/Feb/13 ]

Fixed in both 1.x main trunk, and 2.0 master branch
released Jersey 1.11.2 including the fix.





[JERSEY-1163] Create new chapter in user guide describing differences between JAXB RI and MOXy provider Created: 18/May/12  Updated: 10/Sep/15  Resolved: 24/Oct/13

Status: Closed
Project: jersey
Component/s: docs
Affects Version/s: 1.12
Fix Version/s: 1.18

Type: Task Priority: Critical
Reporter: Michal Gajdos Assignee: Michal Gajdos
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: docs, jaxb, moxy

 Description   
  • take a look at the adjusted tests in JERSEY-1042 patch for inspiration





[JERSEY-988] wadl generator enhancement for JAXB objects with non-public default constructors Created: 16/Feb/12  Updated: 10/Sep/15  Resolved: 01/Mar/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 1.12
Fix Version/s: 1.13

Type: Improvement Priority: Minor
Reporter: aroller Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File WadlGeneratorJAXBGrammarGenerator.java.patch    
Tags: jaxb, maven, wadl

 Description   

We use the wadl to generate client code. The element in the response representation is needed for the client generator to produce the handy method:

 public sandbox.Model getModelAsApplicationXml() {
..
}

Public default constructor of a simple JAXB object (sandbox.Model) produces the correct WADL response element.

<ns2:response>
  <ns2:representation mediaType="application/xml" element="model" />
  <ns2:representation mediaType="application/json" element="model" />
</ns2:response>

Less than public default constructor of the same object produces the correct WADL response element.

<ns2:response>
  <ns2:representation mediaType="application/xml" />
  <ns2:representation mediaType="application/json" />
</ns2:response>

Changing a few lines of Code in the WadlGeneratorJAXBGrammarGenerator now allows for non-public default constructors.

...
return new Resolver() {
  @Override
   public QName resolve(Class type) {
	Object parameterClassInstance = null;
	try {
		Constructor<?> defaultConstructor = type.newInstance();
...

to

...
return new Resolver() {
  @Override
   public QName resolve(Class type) {
	Object parameterClassInstance = null;
	try {
		Constructor<?> defaultConstructor = type.getDeclaredConstructor();
		defaultConstructor.setAccessible(true);
		parameterClassInstance = defaultConstructor.newInstance();
...

Does the trick.

Path file attached.



 Comments   
Comment by Pavel Bucek [ 01/Mar/12 ]

fixed in the trunk, thanks!

Comment by aroller [ 05/Mar/12 ]

that's great. I'll be sure to verify once 1.13 comes out. You guys are great!

Comment by Pavel Bucek [ 05/Mar/12 ]

Actually, it would be better to verify with current snapshot version to give us an opportunity to adjust some things (if necessary) before 1.13 final.





[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-1024] we are having multiple schema which is having same element name and same namespace Created: 03/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Critical
Reporter: androidgalaxyman Assignee: Iaroslav Savytskyi
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 , jboss EAP 6.1 Final , jdk java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)


Tags: jax-ws, jaxb, jaxb-xjc, jboss, metro

 Description   

our application generates the web service classes using JAXB / XJC compiler. we are giving multiple schema as the input to get the java classes for web services . The schema files will be compiled each one and put into the separate packages. assume we are having X and Y schema , just like below mentioned schema. Each schema having same element name , but having the type of complexType .but different complex type. When compilation it will generate the multiple ObjectFactory. This web service , we are trying to deploy in jboss EAP 6.1 ,results the problem of illegalAnnotationException. Can you please anyone advise?

Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
The element name {}row has more than one mapping.
this problem is related to the following location:
at public javax.xml.bind.JAXBElement com.xxx.tws.pojo.XType.ObjectFactory.createRow(com.xxx.tws.pojo.XType.XType)
at com.xxx.tws.pojo.XType.ObjectFactory
this problem is related to the following location:
at public javax.xml.bind.JAXBElement com.xxx.tws.pojo.XTESTType.ObjectFactory.createRow(com.xxx.tws.pojo.XTESTType.XTESTType)
at com.xxx.tws.pojo.XTESTType.ObjectFactory

X:
**
<?xml version="1.0"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty">
<xsd:element name="row" type="XType"></xsd:element>
<xsd:complexType name="XType">
</xsd:complexType
</xsd:schema

Y:
**
<?xml version="1.0"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty">
<xsd:element name="row" type="XTESTType"></xsd:element>
<xsd:complexType name="XTESTType">
</xsd:complexType
</xsd:schema



 Comments   
Comment by androidgalaxyman [ 26/Jun/14 ]

Please close this issue. we have resolved by giving name space for each schema. Thanks

Comment by Martin Grebac [ 26/Jun/14 ]

Thanks.





[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-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-966] unable to honor this schemaBinding customization (MINIMAL and DIFFERENT behavior of command-line xjc from Ant task xjc) Created: 24/Jun/13  Updated: 24/Jun/13

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

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

JDK 1.7.0_21 * JAXB 2.2.7 * Ubuntu 12.04.2


Tags: jaxb, jaxb-xjc

 Description   

Note: this is related to https://java.net/jira/browse/JAXB-965 but IS not identical. See below.

It is different in two respects: (1) it showcases the same kind of bug but in an absolutely minimal setting (with only three, extra-short, xsd files) (2) it demonstrates that in this particular setting, the Ant xjc task fails but the command-line invocation of xjc succeeds which is unsettling but may provide a hint as to the location of this bug.

Here we have three minimal xsd files where invoking the Ant xjc tasks with episodic compilation fails with "unable to honor this schemaBinding" whereas invoking the xjc tool from the command line succeeds. You can view the failure with:

git clone https://github.com/mperdikeas/unable_to_honor-narrowdown.git && cd unable_to_honor-narrowdown && ant

whereas the invocation of the invoke-xjc-2.2.7 succeeds.

Relevant SO post link: http://stackoverflow.com/questions/17274109/jaxb-compiler-was-unable-to-honor-this-schemabinding-customization






[JAXB-965] compiler was unable to honor this schemaBinding customization (in episodic compilation) Created: 24/Jun/13  Updated: 24/Jun/13

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

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

JDK 1.7.0_21 Ubuntu 12.04.2 JAXB 2.2.7


Tags: jaxb, jaxb-xjc

 Description   

When generating Java source files from a bunch of schemas importing one another (and therefore using episodic compilation to avoid having the same classes generated twice), and using some rather complex XSD files (which however I cannot edit since they are industry standard), I get "compiler was unable to honor this schemaBinding customization" failures in random locations. I've created a github repo that captures the case. You can view the "bug" by doing:

git clone https://github.com/mperdikeas/unable_to_honor.git && cd unable_to_honor && ant

Not only will you see the "compiler was unable to honor this schemaBinding" messages, but moreover on successive invocations of "ant clean && ant" you will see the exact line complained about being different (but always the last line in the binding file which to me suggest some parsing bug). I posted on SO on that one as well here:

http://stackoverflow.com/questions/17265960/jaxb-xjc-episodic-compilation-failing-in-random-way-compiler-was-unable-to-ho






[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-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-928] Improper unmarshalling of invalid integer value while schema validation is turned off Created: 04/Nov/12  Updated: 25/Jan/13

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

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

apache cxf, linux


Tags: jaxb, unmarshalling

 Description   

In our product we use Apache CXF as web services framework. Because of performance restriction, the schema validation has been set to false. Now, for an integer element if invalid value is provided, JAXB is unmarshaling it to som other value. For example,

9999999999 is converted into 1410065407.

988888888888 is converted into 1046410808.



 Comments   
Comment by Iaroslav Savytskyi [ 25/Jan/13 ]

Blaise comment here: http://stackoverflow.com/questions/13216624/jaxb-unmarshalling-of-invalid-integer

According to the spec we have to:

  • set 0 into int
  • set null into Integer
  • throw error.




[JAXB-921] Unpredictable marshalling result with extended classes (xsi:type) Created: 02/Oct/12  Updated: 02/Oct/12

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

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

Attachments: Zip Archive XMLMarshallingIssue.zip    
Tags: jaxb, marshalling, xml, xsi_type

 Description   

Hi,

I'm experiencing an intermittent issue with the JAXB XML Marshaller.

Expected Output:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<CreateAnimalResponse xmlns="http://acme.com/animals">
<Bird/>
</CreateAnimalResponse>

Actual Output:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<CreateAnimalResponse xmlns="http://acme.com/animals">
<!-- the xsi type attribute is unexpected here -->
<Animal xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ACME_TYPE_Bird"/>
</CreateAnimalResponse>

Sometimes it works as expected and sometimes it doesn't.

I couldn't find this described as a known issue in the bug tracker.

I think this issue relates to the used object hierarchy:

Animal
+ Bird
+ BirdServer (special component for Database connectivty)
+ Cat
+ Fish

You can find this sample in the attached maven project.






[JAXB-917] Add support for XML schema facets and documentation Created: 04/Sep/12  Updated: 08/May/16

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: 22
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.

Comment by schrepfler [ 28/May/15 ]

Are we getting any closer to get this merged into the JDK?

Comment by Iaroslav Savytskyi [ 04/Jun/15 ]

I would not expect this to be implemented in JAXB RI in some visible time.
As I know Bean Validation was implemented as part of MOXy JAXB implementation.

Comment by schrepfler [ 08/May/16 ]

It's really a shame that Oracle is not taking this contribution, not only because it adds facets support to JAXB but also because it adds Annotation and Documentation as well. The impact would be positive on other things as well, for example the JAXB schemas generated by Jersey would automatically get documentation tags. Please consider this through!





[JAXB-897] JAXB returns "element is already defined" error in case of common schema imports to multiple other schemas Created: 02/May/12  Updated: 28/Jun/12

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

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

JBoss SOA Suite


Tags: import, incomplete, jaxb, schema

 Description   

I have three xsd's defined, each with a different namespace.

One of the xsd is mapped to namespace "Common".

This is imported into two other xsd's with namespaces "Request" & "Response".

The xml schemas with namespaces "Request" and "Response" form the request and response of a single wsdl.

When WSDL2Java is run in Eclipse, the below error is seen -

-------------------------------------------------------------------------------
Failed to Generate Web Service code, please check the log for more details
org.eclipse.core.runtime.CoreException: TODO! Cheek SOAP 1.2 extension
WSConsume (CXF) does not allow to setup the JAX-WS specification target, using JAX-WS 2.1.
Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -compile -d D:\Code\1234\src -verbose -classdir D:\Code\1234\build\classes http://127.0.0.1:8081/USOMET_Poc1/ebws/Core/CustomerService?wsdl
wsdl2java - Apache CXF 2.2.12-patch-02

Failed to invoke WSDLToJava
org.apache.cxf.tools.common.ToolException: Thrown by JAXB: 'BaseRequest' is already defined
at org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error(JAXBBindErrorListener.java:41)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:286)
at com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.java:77)
at com.sun.xml.xsom.impl.parser.ParserContext$2.error(ParserContext.java:202)
at com.sun.xml.xsom.impl.parser.ParserContext$1.reportError(ParserContext.java:180)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.reportError(NGCCRuntimeEx.java:170)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.reportError(NGCCRuntimeEx.java:173)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.checkDoubleDefError(NGCCRuntimeEx.java:145)
at com.sun.xml.xsom.impl.parser.state.Schema.action5(Schema.java:87)
..........
..........
at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:516)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:236)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:85)
at org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:381)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:573)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:228)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:128)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:271)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:232)
at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:230)
at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:81)
Caused by: org.xml.sax.SAXParseException: 'BaseRequest' is already defined
at com.sun.xml.xsom.impl.parser.ParserContext$1.reportError(ParserContext.java:176)
... 43 more
----------------------------------------------------------------------------



 Comments   
Comment by Iaroslav Savytskyi [ 28/Jun/12 ]

Hi, shankyrams,

can you please provide some small simple testcase for this isue. So I'll be able quickly run and fix it.

Thanks a lot.





[JAXB-895] JAXB NullPointerException With Nested HashMap in GF 3.1.2 Created: 10/Apr/12  Updated: 01/Apr/15  Resolved: 12/Apr/12

Status: Resolved
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.5
Fix Version/s: 2.2.6

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

JAXB 2.2.5 embedded in GF 3.1.2. Operating System is Mac OS X Snow Leopard 10.6.8


Attachments: Zip Archive nested-map-example.zip    
Tags: 2-2-5, glassfish-3-1-2, hashmap, jaxb, nested, nullpointerexception

 Description   

It seems that JAXB 2.2.5 is causing a NPE where versions 2.2.4 and older did not. I wrote a simple test EJB inside a Maven project to demonstrate the problem and attached the files.

I have a class named HashMapWrapper that contains a HashMap and provides getters and setters into that map. In the case where an Object value is a nested HashMapWrapper, JAXB throws a NPE when unmarshaling the XML.

I've taken the same test EJB and deployed it in GF 3.1.1 where it works fine, but when I deploy it in 3.1.2, it breaks.

The XML it is attempting to unmarshal is shown below and at the bottom is the exception that is thrown.

<pre>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<hashMapWrapper>
<map>
<entry>
<key>NestedKey</key>
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="hashMapWrapper">
<map>
<entry>
<key>NameKey</key>
<value xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">NestedWrapper</value>
</entry>
</map>
</value>
</entry>
<entry>
<key>NameKey</key>
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">OuterWrapper</value>
</entry>
</map>
</hashMapWrapper>
</pre>

<pre>
Caused by: java.lang.NullPointerException
at com.myexample.HashMapWrapper$JaxbAccessorM_getMap_setMap_java_util_HashMap.set(MethodAccessor_Ref.java:60)
at com.sun.xml.bind.v2.runtime.property.SingleMapNodeProperty$1.leaveElement(SingleMapNodeProperty.java:183)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.endElement(UnmarshallingContext.java:526)
at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.endElement(SAXConnector.java:158)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2939)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:218)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:190)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:172)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:219)
at com.myexample.HashMapWrapper.unmarshal(HashMapWrapper.java:89)
at com.myexample.TestBean.testUnmarshal(TestBean.java:29)
at com.myexample.TestBean.init(TestBean.java:18)
</pre>



 Comments   
Comment by Iaroslav Savytskyi [ 12/Apr/12 ]

Fixed NPE caused by cleaning ThreadLocals in case of nested maps elements

Comment by Iaroslav Savytskyi [ 12/Apr/12 ]

Added new test test/j2s/test/bugs/bug895
Fix barrida: 537

Comment by Nathan Johnson [ 12/Apr/12 ]

If I want to pull that fix into my GF 3.1.2 installation, do I just need to build the jaxb-osgi and jaxb-api-osgi jars and drop them into the GF modules directory and endorsed directory? Or are there other jars that support JAXB in GF? Thanks!

Comment by Iaroslav Savytskyi [ 24/Apr/12 ]

In general you are right. I hope it wouldn't cause any problems because of GF dependencies to older JAXB version.

Comment by ragsboss [ 31/Mar/15 ]

I'm hitting this on my box, exactly for the case of nested maps. Following is my stack trace. As you can see I'm running latest Java 7 with update 60. I think this is not an issue of old jars given this issue got fixed more than 3 years back. Would anyone have any clues?

java.lang.NullPointerException
at com.vmware.vcac.composition.content.fields.ComponentFieldValue$JaxbAccessorM_getData_setData_java_util_Map.set(MethodAccessor_Ref.java:45) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.property.SingleMapNodeProperty$1.leaveElement(SingleMapNodeProperty.java:168) ~[?:1.7.0_60]
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext.endElement(UnmarshallingContext.java:511) ~[?:1.7.0_60]
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.SAXConnector.endElement(SAXConnector.java:143) ~[?:1.7.0_60]
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:203) ~[?:1.7.0_60]
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:175) ~[?:1.7.0_60]
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:140) ~[?:1.7.0_60]
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:123) ~[?:1.7.0_60]
at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmarshal(Jaxb2Marshaller.java:754) ~[spring-oxm-4.1.4.RELEASE.jar:4.1.4.RELEASE]
at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmarshal(Jaxb2Marshaller.java:735) ~[spring-oxm-4.1.4.RELEASE.jar:4.1.4.RELEASE]
at org.springframework.http.converter.xml.MarshallingHttpMessageConverter.readFromSource(MarshallingHttpMessageConverter.java:127) ~[spring-web-4.1.4.RELEASE.jar:4.1.4.RELEASE]
at org.springframework.http.converter.xml.AbstractXmlHttpMessageConverter.readInternal(AbstractXmlHttpMessageConverter.java:61) ~[spring-web-4.1.4.RELEASE.jar:4.1.4.RELEASE]

Comment by Iaroslav Savytskyi [ 01/Apr/15 ]

I've done very brief investigation and I think the reason in that JDK7 contains JAXB 2.2.4 and the bug was fixed in 2.2.5. Plz try to use JDK8. I hope this will fix your problem. If you a not able to upgrade JDK - you will need to use standalone JAXB. In this case you can try JAXB 2.2.11.





[JAXB-889] JAXB Ploymorphism with attributes is broken (throws NPE) Created: 05/Mar/12  Updated: 21/Jan/13

Status: In Progress
Project: jaxb
Component/s: None
Affects Version/s: 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
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
Environment:

Using JAXB 2.2.X as part of CXF 2.4.X


Tags: attributes, jaxb, metro2_2_1-waived, metro2_3-waiver-request, polymorphism

 Description   

I have an abstract identifier class, which has a value. Note that the value is annotated as an xml attribute. This example works if value is annotated as an element.

@XmlSeeAlso({
AbstractIDInt.class
})
@XmlRootElement(name = "AbstractID")
@XmlAccessorType(XmlAccessType.PROPERTY)
public abstract class AbstractID {

@XmlAttribute
abstract Object getValue ();
}

And, here is a class that extends the abstract id class:

@XmlRootElement(name = "AbstractIDInt")
@XmlAccessorType(XmlAccessType.PROPERTY)
public class AbstractIDInt extends AbstractID {
Integer value;

Integer getValue ()

{ return value; }

public void setvalue (Integer value)

{ this.value = value; }

}

If you try to marshal anything that is of type AbstractID, you will get the following exception:
Exception in thread "main" java.lang.NullPointerException
at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:154)
at com.sun.xml.internal.bind.v2.runtime.property.AttributeProperty.<init>(AttributeProperty.java:56)
at com.sun.xml.internal.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:93)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:145)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:479)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:132)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:479)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:305)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1100)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:143)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:110)
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 javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:376)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)

Here is a SO article discussing the issue:
http://stackoverflow.com/questions/9382200/jaxb-and-polymorphism



 Comments   
Comment by Martin Grebac [ 21/Jan/13 ]

Why are you waiving the issue?





[JAXB-882] Marshalling Objects extending JAXBElement linked by @XmlElementRef Created: 22/Feb/12  Updated: 23/Feb/12  Resolved: 23/Feb/12

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

Type: Bug Priority: Major
Reporter: mk0 Assignee: Martin Grebac
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JAXB, Java, XmlElementRef, generate, schema

 Description   

As described here, there is a difference, how JAXB will generate classes:

http://weblogs.java.net/blog/kohsuke/archive/2006/03/why_does_jaxb_p.html

We have the following schema files:

Schema "references.xsd" with reusable elements:

<element name="foo" type="common:sometype"/>
<element name="bar" type="common:sometype"/>

Schema "object.xsd" with some real constructs like:

<element name="object">
<complexttype>
<choice>
<element ref="references:foo"/>
<element ref="references:bar"/>
</choice>
</complextype>
</element>

JAXB will generate a class for the element object and may name it "Object" with an @XmlRootElement annotation on it, while the property for "foo" and "bar" will get optimized the the type "common:sometype". So we will loose the information about the element "foo" and "bar", which causes problems, because this is a choice and JAXB will no longer be able to differ between them. The List accepts the generated class for "common:sometype" twice.

@XmlElementRefs({
@XmlElementRef(name = "foo", namespace = "...", type = CommonSomeType.class),
@XmlElementRef(name = "bar", namespace = "...", type = CommonSomeType.class),
})
protected List<JAXBElement<? extends Serializable>> fooOrBar;

As you can see, JAXB will not be able to know, which CommonSomeType is a "bar" or "foo".

Because of this, I added the following bindings to the binding.xjb:

<bindings schemaLocation="references.xsd">
<bindings node="//xs:element[@name='foo']">
<class name="Foo"/>
</bindings>
<bindings node="//xs:element[@name='bar']">
<class name="Bar"/>
</bindings>
</bindings>

Now, JAXB will generate these two classes "Foo" and "Bar" instead of directly using the "common:sometype"-class for these properties and the choice can be marshalled. This issue is not mainly about the "xs:choice", btw.

The problem is, that the JAXBContext cannot find these two classes in the contextPath, because they look like this:

public class Foo extends JAXBElement<CommonSomeType> {
private QName qname = ....
}

When analyzing JAXBContext.toString() I also do not see them in the list of the known classes.

In this example, the generated Object class looks like this:

@XmlRootElement(...)
public class Object {
@XmlElementRef(name="foo", namespace="...", type=Foo.class)
private Foo foo;
}

How is one supposed to be able to marshal classes, that have properties annotated with @XmlElementRef, which link to classes like Foo?

If you want a real world example, try generating classes using the Sun XACML 1.0 policy schema:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#XACML10

The PolicySet element uses such a choice leading to these problems.



 Comments   
Comment by laune [ 22/Feb/12 ]

There is no point in customizing the types of elements <foo> and <bar>. They can be easily distinguished by their tags. The parent element <object> contains two properties, and after unmarshalling one of them is null, and the other one contains the single child.

Using Thing instead of Object and assuming that Sometype has a property name:

File f = ...;
Thing thing = (Thing)u.unmarshal( f );
Sometype foo = thing.getFoo();
if( foo != null )

{ System.out.println( "foo: " + foo.getName() ); }

Sometype bar = thing.getBar();
if( bar != null )

{ System.out.println( "bar: " + bar.getName() ); }
Comment by mk0 [ 23/Feb/12 ]

Okay, I did a little mistake in my description. The choice is supposed to be an unbounded choice. Please take a look at the Oasis XACML policy schema.

The PolicySetType defines the following unbounded choice:

<xs:choice minOccurs="0" maxOccurs="unbounded">
__<xs:element ref="xacml:PolicySet"/>
__<xs:element ref="xacml:Policy"/>
__<xs:element ref="xacml:PolicySetIdReference"/>
__<xs:element ref="xacml:PolicyIdReference"/>
</xs:choice>

PolicySetIdReference and PolicyIdReference are both of the type xs:anyURI.

The generated List of the object PolicySetType looks like this (I am at home right now not having this in front of me, so this may be a little wrong) (assuming that as:anyURI gets mapped to String):

@XmlElementRefs(

{ __@XmlElementRef(name="PolicySet", ns="...", type=PolicySet.class), __@XmlElementRef(name="Policy", ns="...", type=Policy.class), __@XmlElementRef(name="PolicySetIdReference", ns="...", type=String.class), __@XmlElementRef(name="PolicyIdReference", ns="...", type=String.class), }

)
List policySetOrPolicyOrPolicySetIdRef;

As you can see, the type String appears twice here. So how is JAXB supposed to know, if this is a PolicySetIdReference or a PolicyIdReference?

This is the first bug here.

However, I tried to get around this by customizing PolicySetIdReference and PolicyIdReference, so that JAXB generates classes for them as well. Now, the List in PolicySetType will look like this:

@XmlElementRefs(

{ __@XmlElementRef(name="PolicySet", ns="...", type=PolicySet.class), __@XmlElementRef(name="Policy", ns="...", type=Policy.class), __@XmlElementRef(name="PolicySetIdReference", ns="...", type=MyPolicySetIdReference.class), __@XmlElementRef(name="PolicyIdReference", ns="...", type=MyPolicyIdReference.class), }

)
List policySetOrPolicyOrPolicySetIdRef;

But now you will get IllegalArgumentsExceptions because @XmlElementRef does not support classes, which extends JAXBElement instead of having a @XmlRootElement annotation on them and all the other things they need to become part of the JAXBContext. MyPolicySetIdReference and MyPolicyIdReference are not known to the JAXBContext.

And this results in a blocker, because one is not able to handle this case in any way. I tried everything...

I hope, this is more clear now.

Comment by laune [ 23/Feb/12 ]

Did you try reading the JAXB Tutorial, especially http://jaxb.java.net/tutorial/section_2_2_12_6-Content-A-Mixed-List-of-Elements.html#Content:%20A%20Mixed%20List%20of%20Elements

JAXB inspects the DOM tree and it is the XML elements' tag names that distinguish between elements - not the classes. And you'll have to do likewise when you inspect the list of choices. (Java 1.7 lets you use switch based on String values.)

Below is a full example for you, marshalling and unmarshalling. (If there's still something you don't understand: please use the JAXB users list.)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
version="2.0">

<xs:element name="farm" type="FarmType"/>

<xs:complexType name="FarmType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="hen"/>
<xs:elemeht ref="duck"/>
<xs:element ref="cow"/>
<xs:element ref="pig"/>
<xs:element ref="cowboy"/>
<xs:element ref="milkmaid"/>
</xs:choice>
<xs:attribute name="Name" type="xs:string"/>
</xs:complexType>

<xs:element name="hen" type="BirdType"/>
<xs:element name="duck" type="BirdType"/>
<xs:element name="cow" type="MammalType"/>
<xs:element name="pig" type="MammalType"/>
<xs:element name="cowboy" type="xs:string"/>
<xs:element name="milkmaid" type="xs:string"/>

<xs:complexType name="BirdType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="color" type="xs:int"/>
</xs:sequence>
</xs:complexType>

<xs:complexType name="MammalType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="weight" type="xs:int"/>
</xs:sequence>
</xs:complexType>

</xs:schema>

import java.util.*;
import java.io.*;

import javax.xml.bind.*;
import javax.xml.XMLConstants;

import javax.xml.namespace.QName;

import javax.xml.validation.Schema;
import javax.xml.validation.SchemaFactory;
import org.xml.sax.SAXException;

import generated.*;

public class Main {

private static final String PACKAGE = "generated";
private static final String SCHEMA = "farm.xsd";
private static final String XMLIN = "farm.xml";
private static final String XMLOUT = "farm.xml";

Main(){
}

void unmarshal() throws Exception {
JAXBContext jc = JAXBContext.newInstance( PACKAGE );
Unmarshaller m = jc.createUnmarshaller();

//assign a schema to the unmarshaller
SchemaFactory factory =
SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
try

{ Schema schema = factory.newSchema( new File( SCHEMA )); m.setSchema(schema); }

catch(SAXException e)

{ e.printStackTrace(); }

JAXBElement<?> obj = null;
try

{ obj = (JAXBElement<?>)m.unmarshal( new File( XMLIN ) ); }

catch( Exception e )

{ System.out.println( "EXCEPTION: " + e.getMessage() ); }

FarmType farm = (FarmType)obj.getValue();
System.out.println( farm.getName() );

for( JAXBElement<?> jbe: farm.getHenOrDuckOrCow() ){
String tag = jbe.getName().getLocalPart();
Object value = jbe.getValue();
if( "cow".equals( tag ) ||
"pig".equals( tag ) )

{ MammalType cp = (MammalType)value; System.out.println( tag + ": " + cp.getName() + " " + cp.getWeight() ); }

else if( "cowboy".equals( tag ) ||
"milkmaid".equals( tag ) )

{ System.out.println( tag + ": " + (String)value ); }

}
}

void marshal() throws Exception {
ObjectFactory of = new ObjectFactory();
FarmType farm = of.createFarmType();
JAXBElement<FarmType> jbe = of.createFarm( farm );
farm.setName( "Green River" );

MammalType m1 = of.createMammalType();
m1.setName( "Daisy" );
m1.setWeight( 900 );
farm.getHenOrDuckOrCow().add( of.createCow( m1 ) );
MammalType m2 = of.createMammalType();
m2.setName( "Pinky" );
m2.setWeight( 500 );
farm.getHenOrDuckOrCow().add( of.createPig( m2 ) );

farm.getHenOrDuckOrCow().add( of.createMilkmaid( "Milly" ) );
farm.getHenOrDuckOrCow().add( of.createCowboy( "Jack" ) );

JAXBContext jc = JAXBContext.newInstance( PACKAGE );
Marshaller m = jc.createMarshaller();

m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
// m.setProperty(Marshaller.JAXB_ENCODING, "US-ASCII");

if( XMLOUT == null )

{ m.marshal( jbe, System.out ); }

else

{ m.marshal( jbe, new FileOutputStream( XMLOUT ) ); }

}

public static void main( String[] args ) {
Main main = new Main();
try

{ main.marshal(); }

catch( Exception e )

{ System.err.println( "marshal fails: " ); e.printStackTrace(); }

try

{ main.unmarshal(); }

catch( Exception e )

{ System.err.println( "unmarshal fails: " ); e.printStackTrace(); }

}
}

Comment by Martin Grebac [ 23/Feb/12 ]

Thanks Wolfgang, closing this issue.





[JAXB-871] Disabled fields and multiple-inherence (override once => override for sub-classes) Created: 01/Dec/11  Updated: 18/Jul/12  Resolved: 23/May/12

Status: Resolved
Project: jaxb
Component/s: None
Affects Version/s: 2.2.4, 2.2.4u1
Fix Version/s: 2.2.6

Type: Bug Priority: Major
Reporter: guinotphil Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File BaseObj.java     Java Source File DerivedObj1.java     Java Source File DerivedObj2.java     XML File op1_Response.xml     XML File op1_Response_with_override.xml     XML File op2_Response.xml     XML File op2_Response_with_override.xml     Java Source File package-info.java     Java Source File SampleService.java     File SampleService.wsdl     Java Source File SampleServiceImpl.java     File SampleService_with_override.wsdl    
Tags: inherence, jaxb, override

 Description   

I've been running with an issue caused by the checkOverrideProperties() method which has been added in JAXB 2.2, so I've only been running with this issue since I upgraded the JAXB library in my application..

I'll just give an example, and I think this should be understandable.

Here is my model:

 
public abstract class Parent {
    private String element1;
    private String element2;

    public String getElement1() {
        return element1;
    }

    public void setElement1(String element1) {
        this.element1 = element1;
    }

    public String getElement2() {
        return element2;
    }

    public void setElement2(String element2) {
        this.element2 = element2;
    }
}

@XmlRootElement(name = "child1")
@XmlAccessorType(XmlAccessType.FIELD)
public class Child1 extends Parent {
    private String element1;
    private String element3;

    public String getElement1() {
        return element1;
    }

    public void setElement1(String element1) {
        this.element1 = element1;
    }

    public String getElement3() {
        return element3;
    }

    public void setElement3(String element3) {
        this.element3 = element3;
    }
}

@XmlRootElement(name = "child2")
@XmlAccessorType(XmlAccessType.FIELD)
public class Child2 extends Parent
{
    private String element4;

    public String getElement4() {
        return element4;
    }

    public void setElement4(String element4) {
        this.element4 = element4;
    }
}

@XmlRootElement(name = "wrapper")
@XmlAccessorType(XmlAccessType.FIELD)
public class Wrapper
{
    private Child1 child1;
    private Child2 child2;

    public Child1 getChild1() {
        return child1;
    }

    public void setChild1(Child1 child1) {
        this.child1 = child1;
    }

    public Child2 getChild2() {
        return child2;
    }

    public void setChild2(Child2 child2) {
        this.child2 = child2;
    }
}

Here is the instance of my model:

 
final Child1 child1 = new Child1();
child1.setElement1("element1-1");
child1.setElement2("element1-2");
child1.setElement3("element1-3");

final Child2 child2 = new Child2();
child2.setElement1("element2-1");
child2.setElement2("element2-2");
child2.setElement4("element2-4");

final Wrapper wrapper = new Wrapper();
wrapper.setChild1(child1);
wrapper.setChild2(child2);

Using JAXB 2.2.4 or 2.2.4-1 to marhsall the objects, I get the following XML :

 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<wrapper>
	<child1>
		<element2>element1-2</element2>
		<element1>element1-1</element1>
		<element3>element1-3</element3>
	</child1>
	<child2>
		<element2>element2-2</element2>
		<element4>element2-4</element4>
	</child2>
</wrapper>

As you can see the child2 element minus the element1 subitem. This is because the child1 inherence disabled element1 in parent. Disabling it for child1 is okay, but I don't think it should be disabled for child2 as well.

The easiest workaround is to avoid any override in the java model.

Thank you for your interest.



 Comments   
Comment by Martin Grebac [ 05/Jan/12 ]

This has been introduced with 804 fix, agree it does not work properly. Since there are voices seeing this as a regression even if the child2 property would not be hidden as expected, I think the best solution is to revert this back to the original behaviour, improve the fix and bind it to a switch. I don't want to remove the fix completely because this is closer to what moxy does as well.

Comment by Martin Grebac [ 23/May/12 ]

Fixed in 22 branch.

Comment by gezr [ 18/Jul/12 ]

Added sample web service to reproduce the problem:

Steps to reproduce:

  • Uncomment getDate()/setDate(Date) methods in the DerivedObj1.java class
  • Compile and run service

The difference will be on the response to the SampleService#op2 method call from which ns2:date field disappears:

  • Before override:
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
       <soap:Body>
          <op2Response xmlns="http://services.jaxb.java.net" xmlns:ns2="http://objects.jaxb.java.net">
             <op2Return>
                <ns2:date>2012-07-18T18:10:43.235+02:00</ns2:date>
                <ns2:name>Derived 2</ns2:name>
                <ns2:time>1342627843239</ns2:time>
             </op2Return>
          </op2Response>
       </soap:Body>
    </soap:Envelope>
    
  • After override in DerivedObj1:
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
       <soap:Body>
          <op2Response xmlns="http://services.jaxb.java.net" xmlns:ns2="http://objects.jaxb.java.net">
             <op2Return>
                <ns2:name>Derived 2</ns2:name>
                <ns2:time>1342628337325</ns2:time>
             </op2Return>
          </op2Response>
       </soap:Body>
    </soap:Envelope>
    

Environment:

  • Java:
    java version "1.7.0_05"
    Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
    Java HotSpot(TM) Client VM (build 23.1-b03, mixed mode, sharing)
    
  • JAXB:
    jdk1.7.0_05\bin>wsgen -version
    JAX-WS RI 2.2.4-b01
    
    jdk1.7.0_05\bin>xjc -version
    xjc 2.2.4
    
Comment by gezr [ 18/Jul/12 ]

I understand that the issue was already fixed in 2.2.6 which as far as I know was not released yet. However what bothers me more is that in JDK 7 (up to update 5) the JAXB distribution is still broken. So I have couple of concerns:

  • Will the fix be back-ported to 2.2.4 version?
  • When the fix will be released?
  • Will the fix be included in JDK 7?
  • When such a fix could be included in JDK 7 distribution?

The reason for the JDK 7 question is because we have recently converted project from Java 6 to Java 7 and now we hit this bug. For us it is a blocker for a delivery of our product.





[JAXB-848] Unmarshaller fails to populate collection annotated with @XmlElementRefs Created: 22/Jul/11  Updated: 25/Jul/11  Resolved: 25/Jul/11

Status: Resolved
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1
Fix Version/s: 2.1.14

Type: Bug Priority: Major
Reporter: richard.eggert Assignee: Martin Grebac
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

JDK 6 update 20


Tags: jaxb, unmarshaller, xsd

 Description   

I have a schema that defines a root element containing an <choice> of child elements of the same type (the exact type doesn't matter; in this example I use xsd:token for simplicity), like so:

<xsd:schema targetNamespace="urn:test" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0">
<xsd:element name="testRoot">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="a" type="xsd:token" />
<xsd:element name="b" type="xsd:token" />
<xsd:element name="c" type="xsd:token" />
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:schema>

I ran the schema through Xjc, which output a TestRoot class that looks like this (imports and comments omitted for brevity):

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name="", propOrder=

{"aOrBOrC"}

)
@XmlRootElement(name="testRoot")
public class TestRoot{

@XmlElementRefs(

{ @XmlElementRef(name="c", type=JAXBElement.class), @XmlElementRef(name="a", type=JAXBElement.class), @XmlElementRef(name="b", type=JAXBElement.class) }

)
protected List<JAXBElement<String>> aOrBOrC;

public List<JAXBElement<String>> getAOrBOrC()
{
if (aOrBOrC == null)

{ aOrBOrC = new ArrayList<JAXBElement<String>>(); }

return this.aOrBOrC;
}
}

When I try to unmarshall a file conforming to this schema using the JAXB implementation that ships with JDK 6 Update 20, the "aOrBOrC" property is invariably empty, even when the XML contains a, b, and/or c elements.

Example file:
<testRoot xmlns="urn:test">
<a>foo</a>
<a>bar</a>
<c>baz</c>
</testRoot>

Marshalling seems to work fine, however.



 Comments   
Comment by richard.eggert [ 22/Jul/11 ]

Here are the examples with proper formatting:

Schema
<xsd:schema targetNamespace="urn:test" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0">
   <xsd:element name="testRoot">
      <xsd:complexType>
         <xsd:choice minOccurs="0" maxOccurs="unbounded">
            <xsd:element name="a" type="xsd:token" />
            <xsd:element name="b" type="xsd:token" />
            <xsd:element name="c" type="xsd:token" />
         </xsd:choice>
      </xsd:complexType>
   </xsd:element>
</xsd:schema>
Xjc Generated
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name="", propOrder={"aOrBOrC"})
@XmlRootElement(name="testRoot")
public class TestRoot{

   @XmlElementRefs({
      @XmlElementRef(name="c", type=JAXBElement.class),
      @XmlElementRef(name="a", type=JAXBElement.class),
      @XmlElementRef(name="b", type=JAXBElement.class)
   })
   protected List<JAXBElement<String>> aOrBOrC;

   public List<JAXBElement<String>> getAOrBOrC()
   {
      if (aOrBOrC == null) {
         aOrBOrC = new ArrayList<JAXBElement<String>>();
      }
      return this.aOrBOrC;
   }
}
Input to Unmarshaller
<testRoot xmlns="urn:test">
   <a>foo</a>
   <a>bar</a>
   <c>baz</c>
</testRoot>
Comment by richard.eggert [ 22/Jul/11 ]

I just figured out that it was a problem in my XML. In the example above, the testRoot element should be rendered with a namespace prefix, e.g., <t:testRoot xmlns:t="urn:test"> so that the sub-elements are assigned no namespace. In my original code, I was erroneously instantiating the child elements using the ObjectFactory, which was causing the marshaller to assign namespaces to them.

This ticket can be closed. Sorry for the inconvenience.

Comment by Martin Grebac [ 25/Jul/11 ]

Thanks for self-evaluation ;O), good to know it works for you.





[JAXB-812] JAXB Unmarshalling fails after migrating from Weblogic 8.1 to Weblogic 10.3.3 Created: 02/Feb/11  Updated: 02/Feb/11  Resolved: 02/Feb/11

Status: Closed
Project: jaxb
Component/s: runtime
Affects Version/s: JWSDP1.4 (JAXB1.0.3)
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: rishimathur14 Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

AIX5.3 + Weblogic 10.3.3


Attachments: Text File error.log    
Tags: 1, Jaxb, fail, unmarshalling

 Description   

Hi,
I have an app running on Weblogic 8.1 SP6. I re-built the EAR on Java 1.6 and deployed to Weblogic 10.3.3.
There are a number of JARs used by my app, one of which is a JAR of classes generated from XML schema using JAXB 1.0. I am packaging this JAR as-is, and at run-time get the following error while processing an XML that conforms to the original XSD and valid otherwise. Any pointers is much appreciated! Thanks.
2011-01-31 12:03:50,524 ERROR TranID-[ea68bc59-5af9-4675-a5b0-e494d68303e1][OMF.LocationManagementService.getAddressInfo][Ordermax]RefID-[A24H67U8][] ERROR- javax.xml.bind.UnmarshalException: Unexpected text "2"

  • with linked exception:
    [java.lang.ClassCastException: org.w3._2001.xmlschema.impl.AnyTypeImpl incompatible with ca.bell.jaxb.saquery.response.impl.runtime.UnmarshallableObject] Cause=java.lang.ClassCastException: org.w3._2001.xmlschema.impl.AnyTypeImpl incompatible with ca.bell.jaxb.saquery.response.impl.runtime.UnmarshallableObject message=Unexpected text "2"
    javax.xml.bind.UnmarshalException: Unexpected text "2"
  • with linked exception:
    [java.lang.ClassCastException: org.w3._2001.xmlschema.impl.AnyTypeImpl incompatible with ca.bell.jaxb.saquery.response.impl.runtime.UnmarshallableObject]
    at ca.bell.jaxb.saquery.response.impl.runtime.SAXUnmarshallerHandlerImpl.handleEvent(SAXUnmarshallerHandlerImpl.java:551)
    at ca.bell.jaxb.saquery.response.impl.runtime.AbstractUnmarshallingEventHandlerImpl.reportError(AbstractUnmarshallingEventHandlerImpl.java:148)
    at ca.bell.jaxb.saquery.response.impl.runtime.AbstractUnmarshallingEventHandlerImpl.handleUnexpectedTextException(AbstractUnmarshallingEventHandlerImpl.java:130)
    at ca.bell.jaxb.saquery.response.impl.CircuitInfoTypeImpl$Unmarshaller.handleText(CircuitInfoTypeImpl.java:343)
    at ca.bell.jaxb.saquery.response.impl.runtime.AbstractUnmarshallingEventHandlerImpl.text(AbstractUnmarshallingEventHandlerImpl.java:91)
    at ca.bell.jaxb.saquery.response.impl.runtime.SAXUnmarshallerHandlerImpl.consumeText(SAXUnmarshallerHandlerImpl.java:216)
    at ca.bell.jaxb.saquery.response.impl.runtime.SAXUnmarshallerHandlerImpl.processText(SAXUnmarshallerHandlerImpl.java:220)
    at ca.bell.jaxb.saquery.response.impl.runtime.SAXUnmarshallerHandlerImpl.endElement(SAXUnmarshallerHandlerImpl.java:145)
    at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
    at weblogic.xml.jaxp.WebLogicXMLReader.parse(WebLogicXMLReader.java:133)
    at weblogic.xml.jaxp.RegistryXMLReader.parse(RegistryXMLReader.java:173)
    at ca.bell.jaxb.saquery.response.impl.runtime.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:142)
    at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:148)
    at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:195)
    at ca.bell.persistence.locationmanagement.dao.SAQueryJAXBHelper.unmarshall(SAQueryJAXBHelper.java:75)
    at ca.bell.persistence.locationmanagement.dao.SAQueryAdapter.execute_aroundBody4(SAQueryAdapter.java:124)
    at ca.bell.persistence.locationmanagement.dao.SAQueryAdapter.execute_aroundBody5$advice(SAQueryAdapter.java:573)
    at ca.bell.persistence.locationmanagement.dao.SAQueryAdapter.execute(SAQueryAdapter.java)
    at ca.bell.persistence.framework.dao.BaseDAO.execute_aroundBody0(BaseDAO.java:32)
    at ca.bell.persistence.framework.dao.BaseDAO.execute_aroundBody1$advice(BaseDAO.java:233)
    at ca.bell.persistence.framework.dao.BaseDAO.execute(BaseDAO.java)
    at ca.bell.businessmodel.PersistenceProcessor.execute(PersistenceProcessor.java:136)
    at ca.bell.businessmodel.locationmanagement.bo.LocateCircuitBO.retrieveCircuitDetail_aroundBody0(LocateCircuitBO.java:46)
    at ca.bell.businessmodel.locationmanagement.bo.LocateCircuitBO.retrieveCircuitDetail_aroundBody1$advice(LocateCircuitBO.java:203)
    at ca.bell.businessmodel.locationmanagement.bo.LocateCircuitBO.retrieveCircuitDetail(LocateCircuitBO.java)
    at ca.bell.businessmodel.locationmanagement.function.LocateCircuitBOProcessor.invokeBusinessObject(LocateCircuitBOProcessor.java:42)
    at ca.bell.businessmodel.BusinessProcessor.execute(BusinessProcessor.java:69)
    at ca.bell.businessmodel.locationmanagement.function.LocationManagementBFO.getAddressInfo_aroundBody0(LocationManagementBFO.java:47)
    at ca.bell.businessmodel.locationmanagement.function.LocationManagementBFO.getAddressInfo_aroundBody1$advice(LocationManagementBFO.java:173)
    at ca.bell.businessmodel.locationmanagement.function.LocationManagementBFO.getAddressInfo(LocationManagementBFO.java)
    at ca.bell.webservice.serviceprovider.GetAddressInfoHandler.executeMyTransaction(GetAddressInfoHandler.java:45)
    at ca.bell.common.handler.OperationHandler$1.executeTransaction(OperationHandler.java:48)
    at ca.bell.common.handler.OperationProcessor.execute(OperationProcessor.java:95)
    at ca.bell.common.handler.OperationHandler.execute_aroundBody0(OperationHandler.java:78)
    at ca.bell.common.handler.OperationHandler.execute_aroundBody1$advice(OperationHandler.java:263)
    at ca.bell.common.handler.OperationHandler.execute(OperationHandler.java)
    at ca.bell.autotype.webservices.LocationManagementServiceImpl.getAddressInfo(LocationManagementServiceImpl.java:27)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at weblogic.webservice.component.javaclass.JavaClassInvocationHandler.invoke(JavaClassInvocationHandler.java:134)
    at weblogic.webservice.core.handler.InvokeHandler.handleRequest(InvokeHandler.java:105)
    at weblogic.webservice.core.HandlerChainImpl.handleRequest(HandlerChainImpl.java:144)
    at weblogic.webservice.core.DefaultOperation.process(DefaultOperation.java:551)
    at weblogic.webservice.server.Dispatcher.process(Dispatcher.java:204)
    at weblogic.webservice.server.Dispatcher.doDispatch(Dispatcher.java:175)
    at weblogic.webservice.server.Dispatcher.dispatch(Dispatcher.java:97)
    at weblogic.webservice.server.WebServiceManager.dispatch(WebServiceManager.java:101)
    at weblogic.webservice.server.servlet.WebServiceServlet.serverSideInvoke(WebServiceServlet.java:321)
    at weblogic.webservice.server.servlet.ServletBase.doPost(ServletBase.java:454)
    at weblogic.webservice.server.servlet.WebServiceServlet.doPost(WebServiceServlet.java:292)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.doIt(WebAppServletContext.java:3686)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3650)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
    at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2268)
    at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2174)
    at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1446)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
    Caused by:
    java.lang.ClassCastException: org.w3._2001.xmlschema.impl.AnyTypeImpl incompatible with ca.bell.jaxb.saquery.response.impl.runtime.UnmarshallableObject
    at ca.bell.jaxb.saquery.response.impl.runtime.AbstractUnmarshallingEventHandlerImpl.spawnChild(AbstractUnmarshallingEventHandlerImpl.java:209)
    at ca.bell.jaxb.saquery.response.impl.runtime.AbstractUnmarshallingEventHandlerImpl.spawnChildFromText(AbstractUnmarshallingEventHandlerImpl.java:237)
    at ca.bell.jaxb.saquery.response.impl.CircuitInfoTypeImpl$Unmarshaller.handleText(CircuitInfoTypeImpl.java:336)
    ... 71 more


 Comments   
Comment by Martin Grebac [ 02/Feb/11 ]

Hi, I'm not aware of the jaxb versions weblogic uses, I don't see the jar file you submitted. You shall file a bug against weblogic. Btw, migrating to jaxb2 is certainly recommended.





[JAXB-804] JAXB 2.x : How to override an XmlElement annotation from parent class - Mission Impossible? Created: 11/Jan/11  Updated: 04/May/11  Resolved: 24/Jan/11

Status: Resolved
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.3
Fix Version/s: 2.2.4

Type: Bug Priority: Major
Reporter: bzero Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java SE 6 (latest on Mac OS X 10.6)


Attachments: Zip Archive Archive.zip    
Tags: 3_1-exclude, jaxb, jdk7-applicable, jdk7-integrated, marshalling

 Description   

Please see
http://stackoverflow.com/questions/4661263/jaxb-2-x-how-to-override-an-xmlelement-annotation-from-parent-class-mission-i



 Comments   
Comment by bzero [ 11/Jan/11 ]

Version used of SE6:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)

Comment by Martin Grebac [ 12/Jan/11 ]

Not able to reproduce - tried JAXB RI 2.1.4, 2.1.8, 2.2.4 and get the same result as moxy. Is the code on the forum failing for you? If so, would you please attach it and specify the JAXB version used? Thanks.

Comment by bzero [ 12/Jan/11 ]

I tested with the standalone 1.6.0_22 JRE with no configurations applied regarding JAXB. I don't know what version is used. How can I find this out?

Comment by Martin Grebac [ 12/Jan/11 ]

Well, e.g xjc -version. However, I ran the same JDK and still don't reproduce the issue so I guess my testcase is incorrect? Would you please attach your app or at least the result you get from running your code? Thanks.

Comment by bzero [ 12/Jan/11 ]

The output that gets generated in my case is:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<root xmlns="">
<source>
<string1>1</string1>
<string2>2</string2>
</source>
</root>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<root xmlns="">
<source ns3:type="dataB" xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance">
<string1>1</string1>
<string2>2</string2>
<string3>3</string3>
</source>
<source>
<string1>1</string1>
<string2>2</string2>
<string3>3</string3>
</source>
</root>

When I configure MOXy, I get the correct XML.

SEE ATTACHMENT: Archive.zip

Comment by bzero [ 12/Jan/11 ]

VERSION OF XJC:

xjc version "JAXB 2.1.10 in JDK 6"
JavaTM Architecture for XML Binding(JAXB) Reference Implementation, (build JAXB 2.1.10 in JDK 6)

Comment by Martin Grebac [ 12/Jan/11 ]

Thanks, got it. However, I don't think it's that clear to say who's in error here. Investigating more.

Comment by bzero [ 12/Jan/11 ]

OK. Thanks!
I'm watching this issue, so curious where this ends.

I would like to go back to the standard JAXB RI in the JRE instead of using another lib.

Comment by Martin Grebac [ 12/Jan/11 ]

Adjusting priority and updating status.

Comment by bzero [ 12/Jan/11 ]

Can you comment on the priority downgrade? I think this is critical, it does not marshal objects correctly.
Thanks for taking up this so quickly!

Comment by Martin Grebac [ 24/Jan/11 ]

Fixed in trunk and merged to branches.

Comment by bzero [ 24/Jan/11 ]

How do I get notified when this gets included in the official JRE distribution?

Cheers

Comment by Martin Grebac [ 25/Jan/11 ]

This will certainly go to JDK7. If JDK6 will get updated you'll see in release notes that the included jaxb version has changed and fixes have been incorporated.





[JAXB-801] pluralization of unbounded elements ending in 'ian' and 'y' incorrect Created: 07/Jan/11  Updated: 09/Dec/11  Resolved: 09/Dec/11

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

Type: Bug Priority: Minor
Reporter: smaring Assignee: Iaroslav Savytskyi
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ian, ien, jaxb, plural, xjc, y

 Description   

I had unbounded elements in my schema ending in 'ian' ... example:

<xsd:complexType name="rssIndividual">
...
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="rssPhysician" type="tns:rssPhysician" />
</xsd:sequence>

the result in the POJO from xjc would be 'rssPhysicien' instead of 'rssPhysicians'
note the 'ian' to 'ien'

I used a workaround in my external binding file like so ...

<jaxb:bindings node=".//xsd:complexType[@name='rssIndividual']//xsd:element[@name='rssPhysician']">
<jaxb:property name="rssPhysicians"/>
</jaxb:bindings>

I also had an unbounded element ending in 'y' ... ala ...

<xsd:complexType name="rssPhysician">
...
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="rssPhysicianSurgeryDay" type="tns:rssPhysicianSurgeryDay" />
</xsd:sequence>

the POJO became 'rssPhysicianSurgeryDaies' instead of 'rssPhysicianSurgeryDays'

note that 'y' always seems to become 'ies', but that rule does not work for situations where a vowel preceeds the 'y'

my workaround was similar:

<jaxb:bindings node=".//xsd:complexType[@name='rssPhysician']//xsd:element[@name='rssPhysicianSurgeryDay']">
<jaxb:property name="rssPhysicianSurgeryDays"/>
</jaxb:bindings>



 Comments   
Comment by Martin Grebac [ 09/Dec/11 ]

I don't think we plan to maintain this code further.





[JAX_WS-1119] i am producing jax-ws services using apache cxf.while deploying the war into the server i am getting error Created: 27/May/13  Updated: 25/Jul/13  Resolved: 25/Jul/13

Status: Resolved
Project: jax-ws
Component/s: wsgen
Affects Version/s: 2.1
Fix Version/s: 2.2.8

Type: Bug Priority: Major
Reporter: vrkmurali Assignee: Martin Grebac
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days
Environment:

tomcat 7.0 and eclipse juno


Tags: incomplete, jax-ws, jaxb, jaxws

 Description   

May 27, 2013 6:44:13 PM com.sun.xml.bind.v2.runtime.reflect.opt.Injector inject
WARNING: duplicate class definition bug occured? Please report this : com/iton/dms/documentfunctions/dtosfortemplates/DataForm$JaxbAccessorM_getByteStream_setByteStream_[B
java.lang.ClassFormatError: Illegal class name "com/iton/dms/documentfunctions/dtosfortemplates/DataForm$JaxbAccessorM_getByteStream_setByteStream_[B" in class file com/iton/dms/documentfunctions/dtosfortemplates/DataForm$JaxbAccessorM_getByteStream_setByteStream_[B
at java.lang.ClassLoader.defineClass1(Native Method)
and my dependencies are...
<dependency>
<groupId>javax.xml</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api-osgi</artifactId>
<version>2.2-promoted-b50</version>
</dependency>



 Comments   
Comment by Martin Grebac [ 28/May/13 ]

First of all ... why do you mix 2.1 / 2.2 api versions? Why do you need both osgi and non-osgi bits on classpath? Which version of jaxb impl this actually uses? It'd help if you could get a (best jaxb standalone) testcase for this to reproduce.





[GLASSFISH-20981] Build failure because of invalid pom.xml Created: 13/Feb/14  Updated: 19/Sep/14  Resolved: 18/Feb/14

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.1
Fix Version/s: 4.1

Type: Bug Priority: Blocker
Reporter: HASUNUMA Kenji Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Professional (x86/x64), JDK7 Update 51, Maven 3.1.1


Tags: jax-ws, jaxb, pom

 Description   

When building GlassFish 4.0.1 build 4, the build process is failed with following message. It is because that the specified version of webservices and jaxb does not exist on Maven central repository.

the specified version of webservices in pom.xml is 2.3.1-b259 but latest version on the central is 2.3.1-b104. And jaxb in pom.xml is 2.2.8-b131017.0915 but latest on the central is 2.2.8-b01.

---- Error message #1 ----

[INFO] Common persistence code between JPA and CMP ....... SUCCESS [3.266s]
[INFO] GlassFish Core EJB container implementation ....... FAILURE [0.336s]
[INFO] Full EJB Container add-ons ........................ SKIPPED

(snip)

[INFO] GlassFish Project ................................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23:50.842s
[INFO] Finished at: Thu Feb 13 15:35:45 JST 2014
[INFO] Final Memory: 353M/494M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project ejb-container: Could not resolve depen
dencies for project org.glassfish.main.ejb:ejb-container:glassfish-jar:4.0.1-b04
: Failure to find org.glassfish.metro:webservices-api-osgi:jar:2.3.1-b259 in htt
ps://maven.java.net/content/repositories/promoted/ was cached in the local repos
itory, resolution will not be reattempted until the update interval of jvnet-nex
us-promoted has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyReso
lutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command

[ERROR] mvn <goals> -rf :ejb-container

---- Error message #2 ----

[INFO] GlassFish Web Services related modules ............ SUCCESS [0.175s]
[INFO] JSR-109 implementation to deploy Metro ............ FAILURE [6.597s]
[INFO] GlassFish Metro Glue Code ......................... SKIPPED

(snip)

[INFO] GlassFish Project ................................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 41:45.594s
[INFO] Finished at: Thu Feb 13 15:42:19 JST 2014
[INFO] Final Memory: 461M/494M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project jsr109-impl: Could not resolve depende
ncies for project org.glassfish.main.webservices:jsr109-impl:glassfish-jar:4.0.1
-SNAPSHOT: Failed to collect dependencies at com.sun.xml.bind:jaxb-osgi:jar:2.2.
8-b131017.0915: Failed to read artifact descriptor for com.sun.xml.bind:jaxb-osg
i:jar:2.2.8-b131017.0915: Could not transfer artifact com.sun.xml.bind:jaxb-osgi
:pom:2.2.8-b131017.0915 from/to jvnet-nexus-promoted (https://maven.java.net/con
tent/repositories/promoted/): peer not authenticated -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyReso
lutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command

[ERROR] mvn <goals> -rf :jsr109-impl



 Comments   
Comment by Romain Grécourt [ 13/Feb/14 ]

update assignee, component.

We are aware of this issue, it will be fixed very soon.

Comment by Romain Grécourt [ 18/Feb/14 ]

Issue is resolved: a new metro version has been integrated into GlassFish, and the missing bits have been recovered on maven.java.net.





[GLASSFISH-19287] JAXB 1.0 based applications do not work due to JAXB-899 Created: 05/Nov/12  Updated: 17/Jan/13  Resolved: 17/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: bthalmayr Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jaxb, metro-gf3125

 Description   

Having a web-application which uses classes created by JAXB 1.0.x does not run on GF 3.1.2.2 due to bug JAXB-899

Copying stacktrace from JAXB-899

Caused by: javax.xml.bind.JAXBException

  • with linked exception:
    [java.lang.NoSuchFieldError: theInstance]
    at com.sun.xml.bind.ContextFactory_1_0_1.createContext(ContextFactory_1_0_1.java:100)
    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 javax.xml.bind.ContextFinder.newInstance(Unknown Source)
    at javax.xml.bind.ContextFinder.find(Unknown Source)
    at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
    at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
    at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
    at mypackage.JAXBContextWrapper.getInstance(JAXBContextWrapper.java:57)
    at mypackage.JAXBObjectWrapper.getUnmarshallerStatic(JAXBObjectWrapper.java:161)
    at mypackage.JAXBObjectWrapper.unmarshalStatic(JAXBObjectWrapper.java:184)
    at mypackage.JAXBObjectWrapper.<init>(JAXBObjectWrapper.java:67)
    ... 11 more
    Caused by: java.lang.NoSuchFieldError: theInstance
    at mypackage.generated.jaxb104.impl.runtime.DefaultJAXBContextImpl.<init>(DefaultJAXBContextImpl.java:50)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    at com.sun.xml.bind.ContextFactory_1_0_1.createContext(ContextFactory_1_0_1.java:94)
    ... 24 more


 Comments   
Comment by kumara [ 05/Nov/12 ]

-> web_services because glassfish gets jaxb from metro integration handled through web_services sub component.

Comment by Martin Grebac [ 05/Nov/12 ]

Yarda, please work with Lukas on getting this fixed in a branch for GF 3.1.2.x patch. Thanks.

Comment by bthalmayr [ 05/Nov/12 ]

We try to deliver a JAXB 1.0 based web-application (as we do not have time to migrate it to JAXB 2.0).

As this web-app can be run on fully J2EE compliant container like GF v3 and servlet engines like Tomcat we possibly need to deliver 2 different distro of the application

Old discussion: 'self-contained' vs. 'container-provided' libraries

As JAXB 2.0 should be backward compatible (for all my readings) we actually don't want to bundle any J2EE related libraries with the 'J2EE distro'.

Comment by Martin Grebac [ 07/Nov/12 ]

Yardo, as we're defining jaxb-extra-osgi since metro 2.1.1 for backw. compatibility purposes, I think that would be the right place for jaxb1 as well - what do you think?

Comment by Iaroslav Savytskyi [ 07/Nov/12 ]

Definitely you are right. May be it's also a good idea to mark jaxb-extra-osgi as 'optional' jar.

Comment by Iaroslav Savytskyi [ 21/Nov/12 ]

Hi, all,

as I understand GF 3.1.2.2 uses JAXB 2.2.5.2 which contains JAXB1 classes. So probably problem is somewhere else. We need testcase to reproduce this bug.

Comment by Martin Grebac [ 21/Nov/12 ]

Hi, went again through this more properly - the fix for this went into 2.2.6:

Revision: 3918
Author: snajper
Date: 2012-05-11 15:20:09 UTC
Log Message:
------------
fix for JAXB-899 - keep the jaxb1 required methods, but deprecate all of them + the class -> issue 723 will remain closed because we removed usage of these duplications from the RI2 code and deprecation should (hopefully) make sure we don't start using them again
the whole class should be refactored away eventually in the future - requires little api update since currently it's impossible to reuse the API DTC instead of the RI's one

The bug is not about missing class (thus it is not osgi issue), but about missing theInstance method which was caused as a regression from trying to merge the DTC implementations used in jaxb api/ri. So, I guess the only thing needed is to merge the fix into 2.2.5.x codebase.

Comment by Iaroslav Savytskyi [ 20/Dec/12 ]

Hi,

I've merged 3918 revision to jaxb 2.2.5.3 version.

Comment by Iaroslav Savytskyi [ 17/Jan/13 ]

Should be integrated into 3.1.2.5 GF version.
JAXB SVN revision: 3997





[GLASSFISH-19127] UnmarshalException on abstract class Created: 05/Oct/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Closed
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas Andres Assignee: Iaroslav Savytskyi
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JAXB

 Description   

I have a problem with a webservice, that runs on glassfish 3.1.1, but fails on glassfish 3.1.2.2

@XmlSeeAlso({
	B.class,
	BId.class,
	C.class,
	CId.class
})
public abstract class A {

	private Id id;
}

public abstract class Id {

}

public class B extends A {}

public class C extends A {}

public class BId extends Id {}

public class CId extends Id {}

class B get's a BId at runtime, C a CId.

I have several other places, where I have abstract classes and the webservice serialization works just fine and I see a xsi:type qualifier in the generated xml. In this case however, no xsi:type qualifier is added and I get something like:

<a xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="B">
	<id>
	 ...
	</id>
    ...
</a>

So the unmarshalling can't identify the type of the id and tries to instantiate an abstract Id instead of a subclass.

I noticed, that glassfish since 3.1.2 uses eclipselink moxy and suspect that might be the reason why this fails now.



 Comments   
Comment by Iaroslav Savytskyi [ 18/Jan/13 ]

I've tried to reproduce the problem with a given info in JAXB 2.2.5.3 and 2.2.7 with no luck.
If the problem still exists - please provide small test case.

Comment by Thomas Andres [ 18/Jan/13 ]

Thanks for trying. I'm sorry I don't ahve a clean test case. I've meanwhile worked around the problem.





[GLASSFISH-17383] JAXB can't handle interfaces in Glassfish Created: 06/Oct/11  Updated: 23/Mar/12  Resolved: 23/Mar/12

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mustafarahimi Assignee: Martin Grebac
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Development


Attachments: Text File server.log    
Tags: JAXB

 Description   

We are in the process of migrating our Web Services from Weblogic to Glassfish. The web services worked fine in Weblogic Server, but in Glassfish, JAXB is not able to handle the interfaces. We are getting the following exception:

javax.persistence.EntityManager is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at javax.persistence.EntityManager
at public javax.persistence.EntityManager com.ayenda.services.dal.coupon.ItemFactory.getEm()
at com.ayenda.services.dal.coupon.ItemFactory

I have already read the "unoffical JAXB Guide" on mapping the interfaces to JAXB using annotations. However, the EntityManager class is part of jee and we cannot (should not) modify the source code. Any suggestions ?



 Comments   
Comment by mustafarahimi [ 06/Oct/11 ]

I also wanted to point out that EntityManger is a java persistent class and is not being exposed. Hence, there is no reason for JAXB to marshall/unmarshall this interface. It is an internal class that is being used within the Data Access Layer.

Comment by mustafarahimi [ 10/Oct/11 ]

This might be the same issue as GLASSFISH-7175

Comment by Martin Grebac [ 23/Mar/12 ]

Hi, I think you may be hitting issue where the definition of what methods are supposed to be exposed as jaxws web service methods. This issue has been fixed in GF 3.1.2 - there is a property added which you can specify to revert to the old definition. See http://java.net/jira/browse/JAX_WS-1024 for more details.

If that is not the case and it still doesn't help, GF 3.1.2 bundles eclipselink moxy and also jaxws is able to use eclipselink moxy as a databinding provider: http://metro.java.net/2.2/guide/ch17.html.





[GLASSFISH-16011] JAX-WS/JAXB based Web Service does not recognize XmlJavaTypeAdapter Created: 16/Feb/11  Updated: 19/Feb/11  Resolved: 18/Feb/11

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: v3.0.1
Fix Version/s: 3.1

Type: Bug Priority: Major
Reporter: nbhatia Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: Zip Archive jaxb-jaxws-sample.zip    
Tags: JAX-WS, JAXB, glassfish

 Description   

A web service hosted on GlassFish 3.0.1 does not recognize Java type adapters specified on Java classes. Please see attached sample. The class under question is Position which contains an attribute of type DecimalQuantity.

public class Position

{ @XmlElement(name = "Quantity", required = true) private DecimalQuantity quantity; ... }

DecimalQuantity is annotated with XmlJavaTypeAdapter. So JAXB should use this adapter to serialize DecimalQuantity.

@XmlJavaTypeAdapter(DecimalQuantityAdapter.class)
public class DecimalQuantity

{ private BigDecimal value; ... }

And finally, here's the adapter for DecimalQuantity. It simply converts DecimalQuantity to a BigDecimal and vice-versa.

public class DecimalQuantityAdapter extends XmlAdapter<BigDecimal, DecimalQuantity> {

public DecimalQuantity unmarshal(BigDecimal val) throws Exception

{ return new DecimalQuantity(val); }

public BigDecimal marshal(DecimalQuantity val) throws Exception

{ return val.getValue(); }

}

This adapter works perfectly fine in a unit test which uses JAXB 2.2.3-1 to serialize a Position object (see JaxbTest - to run it simply type mvn test). However, when GlassFish tries to serialize the same object during a web service call it throws the following exception:

Caused by: javax.xml.bind.JAXBException: class test.DecimalQuantity
nor any of its super class is known to this context.
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:594)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:648)
... 45 more

Test this by deploying the WAR generated by the maven project on GlassFish and calling its GetPosition() web service method.

The reason for this exception is that GlassFish 3.0.1 uses an older version of JAXB (version 2.2.1.1) which does not recognize XmlJavaTypeAdapter. This can be proved by replacing the JAXB version in the unit test, it will immediately throw the above exception.

I believe this problem can be fixed by updating the JAXB version on GlassFish to 2.2.3-1. Unfortunately I have tried to do this in several ways without any success.



 Comments   
Comment by Bhakti Mehta [ 16/Feb/11 ]

Assigning the issue to Martin G for more input. Btw Have you tried replacing the jaxb-osgi in the modules folder and jaxb-api-osgi in modules/endorsed to the version you need. That should work

Comment by nbhatia [ 16/Feb/11 ]

I did try replacing jaxb-osgi in the modules folder with jaxb-osgi-2.2.3-1 that I found in the java.net maven repository (renamed the file to jaxb-osgi.jar). That made no difference. I did not try replacing jaxb-api-osgi thinking that there should be no api change between versions 2.2.1.1 and 2.2.3-1. Let me know if that's worth a try.

Comment by Martin Grebac [ 18/Feb/11 ]

Marking as fixed in 3.1.
If you replace the jar file, you need to delete whole $DOMAINDIR/osgi_cache directory, otherwise felix does not replace the jar

Comment by nbhatia [ 18/Feb/11 ]

I replaced the jar file and deleted $DOMAINDIR/osgi_cache directory. Now the server will not start. I see this exception in server.log:

org.osgi.framework.BundleException: Activator start error in bundle com.sun.enterprise.osgi-adapter [92].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1751)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
at org.jvnet.hk2.osgimain.Main.start(Main.java:140)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:640)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.xml.stream.FactoryFinder$ConfigurationError: Provider com.ctc.wstx.stax.WstxInputFactory not found
at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:154)
at javax.xml.stream.FactoryFinder.findJarServiceProvider(FactoryFinder.java:308)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:233)
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:137)
at org.glassfish.javaee.full.deployment.EarHandler.<clinit>(EarHandler.java:113)
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 com.sun.hk2.component.ConstructorWomb.create(ConstructorWomb.java:68)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:71)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at org.jvnet.hk2.component.Habitat$1.get(Habitat.java:276)
at java.util.AbstractList$Itr.next(AbstractList.java:345)
at com.sun.enterprise.v3.server.ApplicationLifecycle.getArchiveHandler(ApplicationLifecycle.java:152)
at com.sun.enterprise.v3.server.ApplicationLifecycle.getContext(ApplicationLifecycle.java:1043)
at com.sun.enterprise.v3.server.ApplicationLifecycle.access$100(ApplicationLifecycle.java:99)
at com.sun.enterprise.v3.server.ApplicationLifecycle$DeploymentContextBuidlerImpl.build(ApplicationLifecycle.java:1006)
at com.sun.enterprise.v3.server.ApplicationLifecycle$DeploymentContextBuidlerImpl.build(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:336)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:185)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:174)
at com.sun.hk2.component.ConstructorWomb$1.run(ConstructorWomb.java:87)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:84)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:77)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:236)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:128)
at com.sun.enterprise.module.bootstrap.Main.launch(Main.java:457)
at com.sun.enterprise.module.bootstrap.Main.launch(Main.java:401)
at org.jvnet.hk2.osgiadapter.HK2Main.start(HK2Main.java:125)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:640)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
... 9 more

I tried to find a matching jaxb-api-osgi.jar, but couldn't find version 2.2.3-1 under http://download.java.net/maven/2/javax/xml/bind/jaxb-api-osgi/. Please advise a next step.

Comment by Martin Grebac [ 19/Feb/11 ]

GF 3.1 uses 2.2.2 version of the api. However, that has not been tested with GF 3.0.1, so there might have been incompatible changes wrt felix class loading which might block you from upgrading jaxb jars.

Comment by nbhatia [ 19/Feb/11 ]

Ok, upgrading to GF 3.1-b43 solves the problem. Any rough time frames on when this will be GA?





[GLASSFISH-15439] @XmlJavaTypeAdapter is not working with Glassfish3.0.1+latest updates Created: 05/Jan/11  Updated: 06/Jan/11  Resolved: 06/Jan/11

Status: Resolved
Project: glassfish
Component/s: jax-rs, other
Affects Version/s: v3.0.1
Fix Version/s: 3.1_ms07

Type: Bug Priority: Major
Reporter: gamliela Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, JAXB hudson-jaxb-ri-2.2.1.1-4


Attachments: Java Archive File simple.jar    
Tags: jaxb

 Description   

I have a web service method that returns, among other things, an java.sql.Date object.

My goal is to serialize this object as Long (e.g. 1292850216296) instead of String representation of the date (e.g. 2010-12-20T15:20:15.265+02:00).

I created a sample program that does this, it works on Glassfish 3 clean install (=JAXB 2.2 something) but doesn't work after upgrading Glassfish to latest version with pkg tool (=JAXB 2.2.1.1-4).
Example program is attached.

Here is the SOAP response when running this program on Glassfish 3 clean install:

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:myMethodResponse xmlns:ns2="http://endpoint_interface.simplepackage">
<return>
<myDate>1292850216296</myDate>
</return>
</ns2:myMethodResponse>
</S:Body>
</S:Envelope>

Here is the SOAP response when running exactly the same program on Glassfish 3 after applying latest updates:

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:myMethodResponse xmlns:ns2="http://endpoint_interface.simplepackage">
<return>
<myDate xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:dateTime">2010-12-20T15:20:15.265+02:00</myDate>
</return>
</ns2:myMethodResponse>
</S:Body>
</S:Envelope>

As you can see xsi:type is different. Is it a bug? Any workarounds?
I cannot upgrade our production environment to Glassfish 3 until this problem is fixed, please help.

Note: maybe the problem is within the JAXB module. JAXB has 2.3 version already, but I don't know how to upgrade JAXB component in Glassfish by it's own; tried to put files in endorsed dir but it didn't work.



 Comments   
Comment by Martin Matula [ 05/Jan/11 ]

Martin, please look into this ASAP.

Comment by Martin Grebac [ 06/Jan/11 ]

Seems like 2.2.1.1 suffered a regression, current trunk/2.2.x codebase does not have the problem.

Comment by Martin Grebac [ 06/Jan/11 ]

So, marking this as resolved since it works fine in 3.1GF, if you must use 3.0.1, using the jaxb osgi jars from 3.1 shall work fine. We'll upgrade our JAXB release jobs to include osgi-fied artifacts in the release bundle as well since it seems it may become handy in these situations.

Comment by gamliela [ 06/Jan/11 ]

OK, thanks for the quick response.
Any clues about when we can expect GF3.1 and/or osgi-fied release of new JAXB ?

Comment by Martin Grebac [ 06/Jan/11 ]

GF roadmap is here: http://wikis.sun.com/display/GlassFish/GlassFishV3Schedule#GlassFishV3Schedule-sectionGlassFishV3SchedulesectionGlassFishV3Sc...
Jaxb will release in a few months.





Generated at Thu Sep 29 13:35:08 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.