Rather than updating the javadoc of a class that might get deleted,
here's an example from one of the Jersey samples:
@Provider
public final class JAXBContextResolver implements
ContextResolver<JAXBContext> {
private final JAXBContext context;
private final Set<Class> types;
private final Class[] cTypes = {Containers.class, Container.class,
Item.class};
public JAXBContextResolver() throws Exception {
this.types = new HashSet(Arrays.asList(cTypes));
this.context = JAXBContext.newInstance(cTypes);
}
public JAXBContext getContext(Class<?> objectType) {
return (types.contains(objectType)) ? context : null;
}
}
The above application class supplies a JAXBContext for the three
classes Containers.class, Container.class and Item.class. This one
doesn't do much of interest but it could set a bunch of properties on
the JAXContext that affect the behavior of marshallers and
unmarshallers obtained from it.
The Jersey JAXB entity provider gets access to providers via an
injected instance:
@Context private ContextResolver<JAXBContext> cr;
and uses this instance to look for an application supplied JAXBContext
for like this:
protected final JAXBContext getJAXBContext(Class type) throws
JAXBException {
if (cr != null) {
JAXBContext c = cr.getContext(type);
if (c != null) return c;
}
// no application supplied context so create own
...
}
The injected ContextResolver is not actually an instance of the
application class JAXBContextResolver, rather it is an implementation-
supplied class that aggregates the set of Providers of a particular
kind (JAXContext in this example) and calls them one-by-one until one
of them returns a non-null context. If no application-supplied
provider return a non-null context then null is returned.
Marc.
On Jun 10, 2008, at 10:33 AM, Stephan Koops wrote:
> Hi Marc,
>> One thing we could consider is to make the JAXBContext usage more
>> obvious.
> I have also to say that I need time to understand what the
> ContextResolver is for. You could add some javadoc, that an example
> use is for JAXBContext.
>
> best regards
> Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.