dev@jaxb.java.net

Re: Life-cycle events (was Re: Complex references)

From: Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_Sun.COM>
Date: Wed, 13 Jul 2005 15:12:42 -0700

Ryan Shoemaker - JavaSoft East wrote:
> Kohsuke,
>
> So, we are going to get rid of c.s.x.b.ObjectLifyCycle and rely on
> reflection to detect the existence of the life-cycle methods?

Yes.

While building JAXBContext, we'll find out if the classes have any of
the life-cycle methods. We'll mark them in JaxBeanInfo so that we can
quickly check if a given class has any of those methods.

The actual invocation needs to be done through reflection. Given that
these methods can be private, that is really the only way.

> Generating a skeleton
> method that we always invoke might complicate the "merging user code"
> issue, but at least it would be obvious to the developers that the
> life-cycle hooks exist.

Those life-cycle methods are more for advanced users, so I don't think
we need to make them that visible. Besides, if we start generating
callbacks for all the beans we generate, that would slow down the
unmarshalling considerably.

> It looks like the current call-backs for unmarshalling are happening
> in the UnmarshallingContext. How much is this going to change when we
> switch to a reflection based approach?

I don't expect much changes in terms of what is done when.

JaxBeanInfo.FLAG_IMPLEMENTS_LIFECYCLE needs to be extended to 4 bits,
and detecting if they are implemented is now more expensive, but there'
is no need for making fundamental changes.

Similarly, invoking an event is more expensive now, but that's a trivial
change.

> Do you foresee any impact from
> re-implementing the unmarshaller?

Not really.

> Where will the life-cycle events be
> triggered on the marshalling side?

I'll address this in another e-mail.

> We also need to figure out a way
> to register life-cycle callback objects for people that want the logic
> outside of the bean. It seems like that may severely limit the kind of
> pre/post processing you can do on the bean, but Joe mentioned that it
> was a requirement from one of the EG members.

I believe the current thinking is to define an event listener and allow
it to be associated to unmarshaller/marshaller.

> I'm not quite sure how
> the registration mechanism is going to work - that will need to be
> specified somehow. Sounds like there are going to be new methods on
> Un/Marshaller to register call-back objects that have the life-cycle
> methods.

Exactly.


-- 
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi_at_sun.com