dev@jaxb.java.net

Re: Integration of FI in JAXB

From: Paul Sandoz <Paul.Sandoz_at_sun.com>
Date: Tue, 08 Aug 2006 11:00:38 +0200

Kohsuke Kawaguchi wrote:
> Paul Sandoz wrote:
>> Hi,
>>
>> I am experimenting with performance improvements to FI integration
>> into JAXB.
>>
>> In the latest FI code case there are the standard FI StAX
>> parsers/serializers and the Enchanced FI parsers/serializers. The
>> latter depend on an enhanced implementation of the former.
>>
>> In the JAXB 2.1 code base there are the standard FI XMLSerializer and
>> StAXConnector implementations and the Enhanced ones. The JAXB runtime
>> will decide on what to use based on whether the standard or enhanced
>> StAX parsers/serializers are present.
>>
>> The reason for this approach is that i wanted to provide some
>> backwards compatibility so that JAXB could be used with older
>> implementations of FI.
> >
>> This approach seemed good when it was in my head but now see it in
>> practice i really do not like it, so a general question: is it
>> reasonable for JAXB 2.1 to depend on FI 1.2 and above for optimal FI
>> integration?
>> (BTW JAXB can always fall back to the non-optimal mode)
>
> IIRC, FI serializer/parser always implement StAX interfaces, so I think
> JAXB can always handle them as just another StAX implementations. Is
> that the case?
>

Yes.


> If so, I think it's probably acceptable to say "JAXB 2.1 needs FI 1.2
> for optimal performance", and "If used with FI 1.0, JAXB 2.1 will work,
> but without any of the FI performance benefits".
>

Me too. I will cut a 1.2 branch for FI.


> What I'd like to avoid is to break existing applications, when those are
> relying on the underlying container to provide them JAXB and/or FI (such
> as any JavaEE apps running inside Glassfish.) They don't have control
> over which JAXB version to use, or which FI version to use (and JAXB
> might come from the container while FI might be bundled in the app.)
>
> So if any of the combination breaks, that's bad. If some combinations
> aren't as fast as it could be, that's much lesser evil to me.
>

Right. The problem i see is how to identify that JAXB should fall back
to the non-optimal approach.

Currently JAXB has no way of knowing and it will blindly try to parse
but then a runtime exception will occur because a method is not present.

I think the best way is to create some new interfaces.

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109