Jeremy Haile wrote:
>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.
>
Thanks for pointing this out. I was not aware of this.
However, after reading it over, there are distinct differences that
make it less attractive for JAXB 2.0.
There are no parameters for the lifecycle events in EJB 3
specification. One can
place the lifecycle callback annotation once on any no parameter method
in the class.
I also noted that a single method can have multiple lifecycle callback
annotations on it in EJB 3.
The lifecycle callback annotation is definitely a savings for this scenario.
It if difficult to envision a single method in a JAXB mapped class ever
being able to
be called for multiple JAXB unmarshal/marshal lifecycle events. Also,
note that the JAXB unmarshal callback
method signatures contains two parameters,one of type
javax.xml.bind.Unmarshaller and another that is the parent object of the
object being unmarshalled. The flexibility of choosing ones own name
for the method
is not as big a win if there are several specialized method parameters.
Lastly,
the annotation approach can be problematic if one places the annotation
on a method
that does not have the correct parameter types.
-Joe
> 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
>>>
>>>
>>>
>>>
>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
>