I think the goal is when someone wants to use those "vendor extension"
features, we make it so that it's obvious that it's not portable. That's
the underlying thinking of the vendor extension mechanism in the schema
compilation, too.
So I wonder if we can have a separate entry point so that you'll do:
JAXBContext context =
com.sun.xml.bind.JAXBRIVendorExtendedContext.newInstance(...);
instead of:
JAXBContext context = JAXBContext.newInstance(...);
Then you can use vendor extension features only when you do it consciously.
Internally, the RI code needs to remember if it's working in the JAXB
mode or the vendor extended mode.
Dmitri Colebatch wrote:
> On 7/13/06, Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_sun.com> wrote:
>> The problem is that the JAXB runtime has no notion of "vendor extension"
>> (unlike schema compilation, where the spec does define such a notion),
>> so such change would make the RI incompatible, which we can't do.
>
> What about an approach where there was support for hooks if a certain
> class existed. eg, in JAXB you did something like:
>
> try
> {
> Class pluginSupport = ....
> pluginSupport.newInstance().doStuff(this);
> }
> catch (ClassNotFoundException e)
> {
> // no plugin support present
> }
>
> plugin support could be some class that looks for a descriptor or
> something, and then allows for a plugin. JAXB RI out of the box
> wouldn't contain this class, and so the above would continue to work
> as per spec (current behaviour) but if someone wanted to work in a
> non-spec manner they could download an additional bundle that
> contained that class and then configure that to use their own plugin?
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com