We Keep Coding

JAXBContext context path vs #XMLSeeAlso

I have gotten confused by these two aspects of JAXB.
As far as I understand, when passing colon separated package names as context path to newInstance method of JAXBContext, JAXB will add all the classes under these packages to its scope to be used in operations like marshall/unmarshall/validate...etc.
The #XmlSeeAlso annotation instructs the JAXBContext to bind classes. All the examples I've seen use this annotation to specify only its child classes (I couldn't tell why actually).
Below are my questions:
1- Can the #XmlSeeAlso be omitted if the classes referred by the
annotation are within the packages passed to JAXBContext newInstance
method?
2- If the above is true, then why do we need this annotation in the first
place, where we can simply pass ALL the packages containing the classes we need to the newInstance
function?
3- If the above is not true, can we only use packages containing top
level classes passed to the newInstance, and use the annotation #XmlSeeAlso to reference all
children of these classes?

1- Can the #XmlSeeAlso be omitted if the classes referred by the
annotation are within the packages passed to JAXBContext newInstance
method?
yes, #XmlSeeAlso is used to instruct JAXBContext to look for classes that is not otherwise loaded by newInstance(). To let JAXBContext to know about the subclasses used, either you can specify with #XmlSeeAlso or pass all subclasses in the newInstance method.
2- If the above is true, then why do we need this annotation in the
first place, where we can simply pass ALL the packages containing the
classes we need to the newInstance function?
#XmlSeeAlso approach is used mostly when you are creating JAXB classes on your own. When you have XSD->JAXB approach, then JAXBContext.newInstance() with all packages separated by : is preferred.

Java class parser

I am parsing all the class files in a jar via Objectweb asm (http://forge.ow2.org/projects/asm/). The idea is to parse and store (and use for something later) all the public/protected methods and fields in each class file. It is working as expected. What I dont get is the list of methods, declared by the interface and those inherited from superclasses and superinterfaces. Is there a smart parser available that would give me the above list?
I could load the class file and then use java.lang.Class object to get what I need. But loading classes might fail because of dependencies. I would rather parse and get that info.

The data you want is simply not there. Inherited members are implicit: you only have the names of the class and interfaces where they can be looked for, and you need to parse the corresponding class files.

You can simply do this :
Class superclass = aClass.getSuperclass();
aClass.getClass().getInterfaces();
aClass.getClass().getMethods();

JAXB - trying to marshall a java object from external jar

I'm trying to marshall this class using jaxb
import com.vividsolutions.jts.geom.Point;
public class TaskPost {
...
Point point;
...
}
(with getters and setters)
Class point is imported from an external jar which i have no source code to, how can i manually marshal this?
I need to use specific methods to get the data from the point class (for now its printing one of the fields SRID>0/SRID> (which are html tags))
Any help would be appreciated.

A JAXB implementation does not require any annotations on a model class so it would apply the default mappings to it. Alternatively, you could write an XmlAdapter to convert Point to/from your own model class for the purpose of marshalling/unmarshalling.

How to handle various concrete implementations of an Interface with JAX-B

I have a class that any I need to marshal to XML.
#XmlRootElement
#XmlAccessorType(XmlAccessType.FIELD)
public class ClassToBeMarshalled {
public Interface object;
}
The Interface is implemented by a lot of concrete classes and most of them are vendor specific whose source code I don't have access to.
So my problem is:
If I try to marshal that class, JAX-B will complain that the current concrete implementation of Interface is not known in the context - In another words, the concrete class was not loaded into the context by calling JAXBContext.newInstance providing the current implementation.
The most common ways to sort out that problem are:
1) Use XMLSeeAlso - not a viable option as there are a lot of concrete classes
2) Annotate each class with #XmlRootElement - not a viable option as I don't have access to all the classes
Does anyone know a way to make JAX-B load the concrete class into its context as the need arises?
Thanks.
P.S.: I'm using JAX-B RI

You could mark your object as #XmlAnyElement(InterfaceHandler.class) where InterfaceHandler is a DomHandler capable of translating between a DOM representation and the actual implementing classes. That handler should probably store the class name when marshalling, and use that class name to create the instance when unmarshalling. It might either configure the instance manually, perhaps using some helper classes designed to work with beans, or it might use another jaxb context which includes that specifically named class and will handle that object with all its nested children.
Also have a look at the #XmlElementRef annotation. I fear that in order to make this work properly, you'd have to at least know all the implementing classes at compile time, but perhaps there is a way you can make this work for you as well, with less trouble than the generic solution outlined in the previous paragraph.

How do I prevent JAXB from binding superclass methods of the #XmlRootElement when marshalling?

I have a class that is annotated as the #XmlRootElement with #XmlAccessorType(XmlAccessType.NONE). The problem that I am having is that the superclass's methods are being bound, when I do not want them to be bound, and cannot update the class. I am hoping there is an annotation that I can put on the root element class to prevent this from happening.
Example:
#XmlRootElement
#XmlAccessorType(XmlAccessType.NONE)
public class Person extends NamedObject {
#XmlElement
public String getId() { ... }
}
I would expect that only the methods annotated #XmlElement on Person would be bound and marshalled, but the superclass's methods are all being bound, as well. The resulting XML then has too much information.
How do I prevent the superclass's methods from being bound without having to annotate the superclass, itself?

According to this StackOverflow post:
How can I ignore a superclass?
It is not possible with JAX-B to ignore the superclass without modifying the superclass.
Quoting the relevant portion of that post:
Update2: I found a thread on java.net
for a similar problem. That thread
resulted in an enhancement request,
which was marked as a duplicate of
another issue, which resulted in the
#XmlTransient annotation. The comments
on these bug reports lead me to
believe this is impossible in the
current spec.

Just add
#XmlAccessorType(XmlAccessType.NONE)
in front of EACH superclass declaration (and the class itself).
In your case:
#XmlAccessorType(XmlAccessType.NONE)
class NamedObject{
[ ... ]
}
Remember that this has to be done really for each superclass, it is often
forgotten when dealing with huge class dependency trees.
Interfaces, of course, don't need any JAXB annotations.

I know this question is quite old, but there is a kind of solution which works if your superclass is in the same package as its child.
Create a package-info.java in your package and insert
#XmlAccessorType(XmlAccessType.NONE)
package my.package.with.classes;
Obviously, it sets XmlAccessType.NONE upon all classes in the package. Myself, I use it in every package in our domain model. Therefore, I'm pretty safe. However, if your class is 'out of reach', f.e. it's in the JDK, use the solution from the accepted answer in [JAX-B] How can I ignore a superclass?.
I hope it's helpful for anynone who stumbles upon this question as I did.

I'm facing the exact same problem.
My superclass does not handle any JAXB annotations (it doesn't have to) and I would like my subclass not to include superclass properties while marshalling.
Adding the XmlAccesorType on superclass cannot be the solution as I have no way to modify the superclass.
Is there any other solution?

Replace your JAX-B implementation with MOXy and you can do anything you want. It has a ton of extensions that go above and beyond normal JAX-B, one of which will allow you to ignore inherited properties, etc. It also supports moving JAX-B annotations to an XML mapping file so you can keep multiple sets of mappings.

A solution I have found, but which might not work for you depending on what you want to do, is to override the getters you want to ignore and let them return null. The JAXB specs, and by extension the implementations, ignore fields that contain a null value. Note that if you still need to be able to access the superclass value itself using the subclass, you may need to add a secondary accessor method that is not a getter and adjust your code accordingly.