moxy

I have been playing with JAXB / MOXy a lot lately, and it works great on all my tests and example codes . I exclusively using binding files, that's why I'm using MOXy. Please note that in all my examples, I'm NEVER using an ObjectFactory nor a jaxb.index, and it works GREAT . When I get back to my business, I get a nasty JAXB Exception saying that my package does not contain an ObjectFactory or jaxb.index. My project also invovles Spring and Hibernate, JUnit and DBUnit. Here is some sample code: I have an abstract class called AContributionPhysicalSupport. package org.pea.openVillages.pojo

When I use @XmlSchema(attributeFormDefault = XmlNsForm.QUALIFIED, ...) or @XmlAttribute(namespace = "sample.com/y", ...) JAXB ignores @XmlSchema(namespace = "sample.com/x", ...) and instead of: <a xmlns="sample.com/y" xmlns:ns0="sample.com/y"> <b ns0:att=""/> </a> generates something like: <ns1:a xmlns:ns1="sample.com/x" xmlns:ns0="sample.com/y"> <ns1:b ns0:att=""/> </ns1:a> Is this an expected behavior? Is there any way to correct this? EclipseLink JAXB (MOXy) is handling the prefix qualification for elements differently depending upon the attribute form qualification (as demonstrated below).

I followed the Jersey 2.0 document ( https://jersey.java.net/documentation/latest/user-guide.html#json.moxy ), modified pom.xml, included jersey-media-moxy artifact, compiled and installed. I could get basic POJO to JSON mapping work for both Produces and Consumes cases. However, when I tried with some POJO with complex data type as resource return type, I got a lot Status 500 Internal Server Error but without any server log. It is very annoying. Does anybody know if it is a bug or I missed something in configuration? By the way, in order to use Moxy mapping for a POJO object, the POJO needs

I am trying to use MOXy as my JAXB provider in order to marshal/unmarshal content into XML/JSON. I have created the "jaxb.properties" file with as content : javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactor Everything works fine. JAXBContext jaxbContext = JAXBContext.newInstance(ServerInformation.class); // The jaxb.properties must be in the same package as "ServerInformation.java" Marshaller marshaller = jaxbContext.createMarshaller(); marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true); marshaller.setProperty(MarshallerProperties.MEDIA_TYPE, MediaType

In http://blog.bdoughan.com/2013/06/moxy-is-new-default-json-binding.html about halfway down there's a heading "Customizing the JSON-Binding". How do you similarly customize the XML binding? There seem to be fundamental differences between the way Jersey handles Moxy JSON binding and the XML equivalent. If I follow the instructions in the Jersey documentation for creating a custom JAXBContext resolver to configure Moxy's mapping file, that resolver fires in the JSON case but not in the XML case. See https://bitbucket.org/jmetcher/resttest/ for a very small project demonstrating this. I have

I was reading over the answer for Moxy ignore invalid fields in json and the approach matched something I'm trying to do, so I decided to give it a shot.. I created a feature to disable the default ConfigurableMoxyJsonProvider; @Provider public class JsonFeature implements Feature { @Override public boolean configure(final FeatureContext context) { final String disableMoxy = CommonProperties.MOXY_JSON_FEATURE_DISABLE + '.' + context.getConfiguration().getRuntimeType().name().toLowerCase(); context.property(disableMoxy, true); return true; } } And I created a really simple custom provider;

I'm trying to parse some XML with EclipseLink MOXy, and it's failing on the line with the xsi attribute. If I remove this, it parses fine. However, I've got 100GiB of XML to wade through and changing the source files is not an option. It's been suggested that if I can set XmlParser.setNamespaceAware(false) then it should work - but I've got no idea how to configure this, without breaking right into the guts of MOXy. <record> <header> <!-- citation-id: 14404534; type: journal_article; --> <identifier>info:doi/10.1007/s10973-004-0435-2</identifier> <datestamp>2009-04-28</datestamp> <setSpec>J<