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
>
>
>
attached mail follows:
On 7/14/05, Joe Fialli <Joseph.Fialli_at_sun.com> wrote:
> The public draft of the JAXB 2.0 specification[1] documents the
> unmarshal and marshal callback events in Section
> 4.4.1 and 4.5.1. The JAXB mapped class will not have to implement the
> ObjectLifeCycle interface,
> it just has to define the precise method signatures defined in the
> specification. As Kohsuke mentioned,
> the RI originally prototyped this functionality and thus the RI and spec
> are not synchronized on this functionality yet
> but will be in future.
Thanks - that all makes sense. Similar to Serializable etc.
cheers
dim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net