Eclipse: generate JAXB classes: Please insure that a JAXB implementation is available ....

The classpath for this project does not appear to contain the necessary libraries to proceed with class generation. Please insure that a JAXB implementation is available on the classpath.


What you need is available in a Web Services project:

JAXB, retrieving the Namespace of an element

I hate hardcoding namespaces in my code, so here is how to retrieve it from the JAXB annotated beans:


ObjectFactory oj = new ObjectFactory();
String NAMESPACE = oj.createMyObject(oj.createMyObject()).getName().getNamespaceURI();

Quick Java code to convert a Java object into XML

I keep having to do it and I keep forgetting...

private static String objectToXML(Object object, Class clazz) throws JAXBException,
 PropertyException {

 JAXBContext jc = JAXBContext.newInstance(clazz);
 Marshaller marshaller = jc.createMarshaller();
 marshaller.setProperty( Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE );
 ByteArrayOutputStream baos = new ByteArrayOutputStream();   
 marshaller.marshal(object, baos);
 return new String(baos.toByteArray());
}
 

This is another working example (courtesy of Adam Bien):

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

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Duke {
 private String language;
 private int age;
 
 
 @Override
 public String toString() {
  return "Duke [language=" + language + ", age=" + age + "]";
 }

 public Duke(String language, int age) {
  super();
  this.language = language;
  this.age = age;
 }
 
 public Duke() {
  
 }
 
}





import java.io.File;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;

import org.junit.jupiter.api.Test;

public class DukeTest {
 @Test
 public void testSerialization() throws JAXBException {
  JAXBContext context = JAXBContext.newInstance(Duke.class);
  Marshaller marshaller = context.createMarshaller();
  marshaller.marshal(new Duke("Java", 2), new File("duke.xml"));
  Unmarshaller unmarshaller = context.createUnmarshaller();
  Object unmarshalled = unmarshaller.unmarshal(new File("duke.xml"));
  System.out.println(unmarshalled);
 }
}

XML Streaming Parsing: a desert populated by skinny animals

Having to implement a XML Streaming parser is no fun these days.

On one hand, you have a solid technology which is JAXB. Wonderful. But it doesn't handle streaming. So if you have a 1 GB document to parse, you are screwed.

On the other hand, you have SAX and StAX.... well I have played a few hours with StAX, and I can't really see the improvement over SAX, apart from the silly "pull" approach over the "push" approach... so what? Basically you still have to handle individual atomic events (startElement, characters, stopElement) and manually reconstruct your Java XmlEntity from them.... painful if you have complex Entities...

StAX is useful only if you need to parse bits and pieces of information here and there, without having to parse the whole thing. Otherwise, FIASCO.


Finally I resorted to using the excellent java.util.Scanner class to locate the start of an element, and read until the end of the element into a String, then use JAXB to parse the String into a XmlEntity.... it works like a charm.

you just need to annotate your entity as @XmlRootElement - no worries you can have multiple XmlRootElement in your file, and you can annotate even a static class.


I see here a big need for a streaming technology that can still make use of JAXB... it seems not too difficult to implement... or some adjustments on StAX so that it can call JAXB...

MFL+JAXB versus pure Java parsing

Disclaimer:   this test was done in Eclipse using WLXT. The test proves to be INCREDIBLY slower compared to running the same MFL transformation inside OSB. In fact, inside OSB reading 418 binary files (5 KB each) and writing them in XML format took roughly 8 seconds - a LOT better than the 155 seconds using WLST.
I am curious now to understand where lies the HUGE difference in performance of the Format Builder libraries when run in OSB and in Eclipse.

Morale: don't benchmark MFL using a out of container test.

I have 417 files containing "binary" messages, fixed length fields, to be parsed into Java objects. Each file is some 5 KB each. Total some 2 MB.

Doing the transformation:
Binary -> XML (with MFL) followed by
XML -> Java (with JAXB)

inside Eclipse takes a whopping 157 seconds, out of which 101 in MFL and 56 in JAXB.
The same transformation run on a OSB proxy service takes some 5 seconds (!!!).

Doing the transformation Binary -> Java directly in Java takes 3.5 seconds - that is some 50 times faster. I assume the memory garbage produced would be also immensely lower by parsing directly in Java.

The Java parser took 4 hours to build and test. MFL took 2 hours to make and 2 hours to troubleshoot.

JAXB generate Java classes from xsd

Using Excel, I have mapped a MFL to a XSD; now I want to generate the Java classes corresponding to the XSDs. JAX-WS uses JAXB as data binding, so:

http://java.sun.com/webservices/docs/1.6/jaxb/xjc.html

I use xjc.bat to generate the Java classes.

The alternative is: create a WebLogic WebService project, copy there your XSD, right click and "WebLogic WebServices / generate JAXB types", which internally invokes the XJC2Task Ant task.

XmlAccessType.FIELD vs XmlAccessType.PROPERTY

As a Java guy, I feel disturbed by using XmlAccessType.FIELD
(see
http://java.sun.com/javase/6/docs/api/javax/xml/bind/annotation/XmlAccessType.html )
in JAXB while "exposing" a JavaBean as a XML data type.

XmlAccessType.FIELD will expose ANY Java attribute, even the private ones, even those that you didn't mean to expose, UNLESS you annotate them as @XmlTransient .


MY vision, which I assume matches the JavaBean vision, is that you expose only properties which are explicitly associated with a getter (setter if they are writable), and that you should really never access directly the attribute as a field. This leads to a more method-centric programming style, as opposed to a data-centric programming style.

For this reason, I privilege the XmlAccessType.PROPERTY approach.