7

I've got a set of JAXB generated classes and some of the classes have setter methods which accepts "Object" as the parameter. For example:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name="Car", propOrder = {
    "defaultCar"
} 

public class Car {
  @XmlElement(name = "DefaultCar") 
  protected Object defaultcar;  

  public void setDefaultCar(Object value) {
    this.defaultCar = value;
}

After I've created instances of these classes in my code, I call the setter methods passing in the required value. Although the method's parameter is Object, the values are most likely to be strings (I've got no control over how it is defined). However, to keep things consistent, I cast the string to Object so that it matches the method's parameter type. The code looks something like this:

    Object value = "Old Banger";
    Method method = aCar.getClass().getMethod("setDefaultCar", Object.class);
    method.invoke(aCar, value);

When I marshall the Java objects, I get the following within the resulting XML, just in front of the value of the string:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string" 

I've read somewhere about mismatching data types between the method's parameter type and what has been passed to it. In my case the method parameter being "Object" but I'm passing in a string to it (although I've cast it to Object). I've also seen this post and it looks similar to my problem:

"xsi:type" and "xmlns:xsi" in generated xml by JAXB

However, it doesn't help me overcome my problem. Is there a way to remove these references to xmlns:xsi and xsi:type?

Thx

Community
  • 1
  • 1
user3572079
  • 135
  • 1
  • 2
  • 12

3 Answers3

5

JAXB exports xsi:type if your data specifies other type than your model. In your case, you set a string, but the field is Object. So your data has a different type than your model. The behaviour is correct.

How you can fix that. You have align the type of the property with the type of the data. There's quite a number of ways to achieve that:

  • Make it String, why is it an Object in the first place?
  • Update: You can use jaxb:javaType binding for that.
  • Ùse @XmlElementRef/@XmlMixed combo instead.

However, to keep things consistent, I cast the string to Object so that it matches the method's parameter type.

What do you think happens to the string when you cast it to object? :)

lexicore
  • 42,748
  • 17
  • 132
  • 221
  • thx for confirming my understanding of what's happening. Unfortunately, I can't change the type from Object to String as the XSD has been supplied to me (I did play about the method and changed it to accept String and the xsi:type goes way like you've said). Any good links to your second suggestion or does that involve changing the JAXB classes too? I'm using Eclipselink MOXy BTW. Is there some sort of feature that I can use? When I tried to cast the String to Object I was clutching at straws but with no luck! ;) – user3572079 Nov 25 '14 at 16:48
  • @user3572079 You can't change the schema but you can customize, for instance using `jaxb:javaType`, see the update. – lexicore Nov 25 '14 at 17:04
4

You can always override the property type using the type parameter on the @XmlElement annotation.

  @XmlElement(name = "DefaultCar", type=String.class) 
  protected Object defaultcar;  
bdoughan
  • 147,609
  • 23
  • 300
  • 400
  • Thx Blaise, I read your solution to the other person who had a similar problem to me and thought I could use it too. However, it would be preferable not to alter the classes generated by JAXB but to code it in my program instead. I was hoping you pick up my question but it seems that EclipsLink MOXy doesn't provide any means to prevent this from happening then? :( – user3572079 Nov 25 '14 at 17:02
0

I had similar problem. I was sending XML with these attributes to some WS that was not able to handle it. I remember that I was using Apache CXF for sending this XML so I ended up with CXF interceptor that handled removal of these attributes.

Sadly, I didn't find a way how to "disable" generation of these attributes directly in JAXB. What you can do (and probably will be the only way to solve it) is that you take your generated XML and process it once again with another (DOM/SAX) API and remove attributes manually. It is definitely not a nice solution but I'm not sure if you find better :-/

I would be happy if anyone gives you a better answer...

zdenda.online
  • 2,451
  • 3
  • 23
  • 45
  • I did read some forums which mentioned writing an XML filter (I guess similar to what you've done) but I was hoping there was a more cleaner solution – user3572079 Nov 25 '14 at 16:12