Have you considered supporting annotations for lifecycle methods? This
would be consistent with the way lifecycle events are processed in the
EJB 3 specification. It would also be more flexible than requiring a
special naming convention. My personal opinion is that following a
particular naming convention (like MBean interfaces) is going to become
less common in the future in favor of annotations. I think JAXB 2.0 is
especially a good place to follow this pattern since it is only targeted
at JDK 1.5 and above.
Although, in my case I don't want my mapped objects tied to JAXB at all
and would rather have a separate object listening for lifecycle events
(as you have said JAXB will provide).
Jeremy
On Fri, 15 Jul 2005 12:44:58 -0400, "Joe Fialli" <Joseph.Fialli_at_Sun.COM>
said:
> Jeremy Haile wrote:
>
> >If I understand it correctly, on order to receive object lifecycle
> >events, the object that is being bound to XML must implement
> >ObjectLifecycleListener.
> >
> > What I don't like about this is that it forces
> >the developer to introduce a coupling between the JAXB classes and the
> >mapped object.
> >
> That is how it is implemented now in RI. It is specified in JAXB 2.0
> public draft that if
> the object implements specific method signature, the method will be
> called.
> I have attached my previous response that summarizes what JAXB 2.0 RI
> will be implementing in future.
> Thus, a JAXB mapped class will not be required to implement a JAXB
> specific interface.
>
> > Although I don't have a problem with this listener
> >interface being part of the spec, I think it would be useful to have a
> >listener interface that can be implemented by any class interested in
> >object lifecycle events.
> >
> >For example, the way Castor currently works is that there is a
> >MarshallListener and an UnmarshallListener interface that can be
> >registered with the Marshaller or Unmarshaller. Any class can implement
> >this and then receives lifecycle events for every object that is
> >marshalled or unmarshalled. This way, your XML-mapped classes do not
> >have to be coupled by implementing JAXB interfaces.
> >
> >
> We plan on adding this functionality to the specification before PFD.
> We got this request too late
> to add to public draft. The use case for this scenario is that the
> developer might have some classes that
> they consider read-only and they do not wish to modify them. Since this
> mode is not as powerful
> as supporting the event callbacks being in the same class, we intend to
> support both ways.
> It is more powerful to actually place the methods in the class since
> these methods are
> able to access private methods and members (very useful if what your
> intention is to use beforeUnmarshal()
> event callback to initialize private fields to specific default values).
>
> -Joe Fialli, Sun Microsystems
>
> >Jeremy Haile
> >
> >
> >On Tue, 12 Jul 2005 17:31:02 -0700, "Kohsuke Kawaguchi"
> ><Kohsuke.Kawaguchi_at_Sun.COM> said:
> >
> >
> >>Dmitri Colebatch wrote:
> >>
> >>
> >>>thanks - but this is part of the spec right? why isn't it in the jaxb
> >>>package? not that I have anything against the RI, but shouldn't we be
> >>>writing our code so that we can change implementation without changing
> >>>the code?
> >>>
> >>>
> >>I think we are planning to move the functionality into the spec, but our
> >>current thinking is to make it not an interface (so that you can
> >>selectively implement it, so that you don't have to make those methods
> >>public, etc.)
> >>
> >>Sometimes we do experiments within the RI before moving that up to the
> >>spec, and this is one such instance.
> >>
> >>--
> >>Kohsuke Kawaguchi
> >>Sun Microsystems kohsuke.kawaguchi_at_sun.com
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> >For additional commands, e-mail: users-help_at_jaxb.dev.java.net
> >
> >
> >
>