Hi,
I think this issue needs to be brought up at the spec level. Basically, the
following have to be clarified:
1) What interfaces are qualified to be remotable?
2) What are the characteristics of the input/output types for remotable
interfaces?
3) What are the semantics of pass-by-value?
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, November 28, 2007 7:55 AM
Subject: Re: Data transformation from/to POJO
Simon Nash wrote:
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
Raymond Feng wrote:
I think there are two options:
1) Make the JAXB databinding as the default databinding for POJOs
(simple and complex types).
What about doing that? any drawback?
And, jumping ahead and assuming that any drawbacks are acceptable, what
about using that as well instead of where we currently use Java
serialization to achieve "pass by value" through remotable interfaces.
That'll allow us to remove the requirement for objects that flow through
a remotable interface to implement java.io.Serializable, which is not
quite right.
I think the main issue we need to resolve in order to make this change
is to solve the problem with passing interface types that has been raised
on the user list. Java serialization takes care of this by encoding the
class name in the serialized form.
There are also likely to be a number of restrictions on what is allowed
in the object being copied that are imposed by the default JAXB mapping
but don't apply to Java serialization. I'm a bit concerned that we could
end up with limitations that are more severe than the current limitation
of needing to implement java.io.Serializable.
I prefer to have consistent rules (with respect to what the business
objects can look like or must implement) between a remotable interface
bound to an XML-based binding and a remotable interface used for in-VM
communication.
Different rules make it confusing or impossible to rewire your application
without changing your business objects.
I ran into this right away in step 2 of the store tutorial (merger). The
Item bean was working well over XML, but broke when I tried to pass it
through an in-VM call (see the wire between Catalog and FruitsCatalog in
store-merger.composite).
Another alternative to using Java serialization is to write an in-memory
reflective cloning function. This would probably be more efficient
than serialization, would not require java.io.Serializable, and should
be able to support pretty much any Java object.
There's also the possibility of a hybrid approach, where we would use
Java serialization if the object implements java.io.Serializable and
some other approach (e.g., JAXB or cloning) if it doesn't.
How about starting simple with one option that's consistent with the spec
and really works instead of three that work differently?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
