Hi Raymond,
1) Here is the method that I have done to the DataBinding interface ...
Object copy(Object source);
At the present moment I cannot think of any context that can also be added
as an argument to this method. Will do so if it evolves to that as we go
along.
2) I also implmented the 'copy' method in the AxiomDataBinding and
SimpleDataBinding classes to take care of OMElement and Node objects. I am
using the transformers effectively in this regard.
3) After this I have been able to run the echo.databinding sample (which has
been breaking) half way through. This time around I am stuck with the
XMLStreamReader which is not serializable and is not taken care of any of
the databindings. This on one hand and on the other I really cannot make
sense of copying streams or stream readers as part of enforcing
passbyvalue.
All this means that there are going to be some objects types that we should
not be copying and then some that we don't know how to copy. What is the
'general' strategy to follow on what objects to copy and what not?
- Would it be like we copy if we know the databindings to which they
conform or if they are serializable java objects. When we don't know how to
copy do we raise exceptions or do we simply pass thro.
- What about the list of object types such as XMLStreamReader which
actually may not make sense to copy. What will be the marker that we can
use to identify these sort of object types.
4) While using the transformers to implement the copy method in the
AxiomDataBinding and SimpleDataBinding I observed that what we are trying to
do here is a round-trip transformation for example to copy OMElement I do a
OMElement2String and then a String2OMElement. So am wondering if we could
make use of the 'data mediation' always instead of using just when there is
a disparity between source and target databindings. i.e.
- When databindings between source and target are different, currently there
is data mediation that is performed. When this is perfomed, there is no
need to copy since anyway a new data object is created.
- When datatbindings between source and target are the same, currently there
is 'no' data mediation performed. But why not do it here also but a round
trip transformation. So we define a set of 'round trip transformers' that
take you from a source type to a target type and then back to the source
type, returning a copy at the end of it all.
Thanks for reading this far and please let me know your thoughts on all of
this.
- Venkat
On 12/13/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
Hi Raymond,
Thanks. Am going ahead with this.
- Venkat
On 12/13/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi, Venkat.
>
> You don't have to create a new extension point here as we already have
> one:
>
> org.apache.tuscany.spi.DataBinding
> org.apache.tuscany.spi.DataBindingRegistry
>
> You can just add the copy(...) method to
> "org.apache.tuscany.spi.DataBinding".
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Wednesday, December 13, 2006 2:39 AM
> Subject: Re: Pass-by-value support for remotable interfaces
>
>
> > Hi Raymond,
> >
> > Here is what I have thought about the databinding dependent copying: -
> >
> > - Create an interface called 'DataCopier' that has 'copy' and
> > 'getDataBinding' methods.
> > - Have various databindings implement this interface. For example
> > OMElementCopier, SDOCopier and so on.
> > - In the PassByValueInterceptor, have 'copier' object. i.e. in the
> wire
> > post
> > processor we look at the databinding of the target and create an
> > appropriate
> > copier. We then configure the PassByValueIntercpetor with this copier
> > object. As part of the invoke method the interceptor will call the
> > Copier's
> > copy method.
> > - As in the case of transformers, we can have a registry of copiers
> keyed
> > by
> > their databinding.
> >
> > Will this approach work? Have I missed out something in this
> ? Thanks.
> >
> > - Venkat
> >
> > On 12/8/06, Jim Marino < [EMAIL PROTECTED]> wrote:
> >>
> >> >
> >> >
> >> > Well here is what I picked up from the specs and C&I model
> >> > "The @AllowsPassByReference annotation on the implementation of a
> >> > remotable
> >> > service is used to either declare that calls to the whole interface
> or
> >> > individual methods allow pass by reference." and "Either a whole
> >> > class
> >> > implementing a remotable service or the individual remotable
> >> > service method
> >> > implementation can be annotated using the @AllowsPassByReference
> >> > annotation.
> >> > "
> >> >
> >> > and then there are samples as well that show the annotations being
> >> > used in
> >> > these two ways. HenceI have stared to think this way.
> >> >
> >> Yes they are in there but I believe we changed that and may not have
> >> updated the spec. At least that was my and Mike Rowley's
> >> recollection. Let me check tomorrow. We've changed a number of
> >> things back and forth so it's quite possible I don't remember where
> >> we wound up. If it is per operation, that is potentially very error-
> >> prone so I will take it up with the spec group.
> >> >
> >> >
> >> > I am yet to take a look at the PolicyBuilder related stuff. Will
> >> > take this
> >> > to completion and then migrate to that. I am most certain it
> >> > would be no
> >> > problem fitting this stuff there once I have the basic things
> >> > working. What
> >> > do you feel?
> >> I don't know but I would hope there are not problems - if not let me
> >> know and I'll try to help.
> >>
> >> Jim
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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]
>
>
