On 4/23/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 23, 2008 at 12:43 PM, Ramkumar R <[EMAIL PROTECTED]> > wrote: > > > On 4/18/08, Ramkumar R <[EMAIL PROTECTED]> wrote: > > > > > > On 4/18/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > >> > > >> On Fri, Apr 18, 2008 at 9:18 AM, Ramkumar R <[EMAIL PROTECTED]> > > >> wrote: > > >> > > >> > TUSCANY 1881, talks about throwing a warning msg when adding remote > > >> > bindings > > >> > to services with interfaces not marked as remotable, by which the > > data > > >> > transformation might get messed up. > > >> > > > >> > From the current implementation, I understand that the > > >> datatransformation > > >> > interceptor will not be inserted in the invocation chain if the > > target > > >> > interface is not marked as remotable. Not having this interceptor > > will > > >> end > > >> > up with binding specific data transformations not being done.. So > > unless > > >> > the > > >> > target binding does have any trouble with the arguments and > > returntypes > > >> > because of the absence of transformations... we do not have any > > issues. > > >> > But > > >> > otherwise we might end up in runtime exceptions being thrown. > > >> > > > >> > While thinking at a solution to this issue, i could think of various > > >> > options > > >> > as shown below, but not sure which one is the right approach? > > >> > > > >> > OPTION 1: About issue shows how lack of Remotable ends up in runtime > > >> > exception when service methods are invoked, can't we somehow trap > > this > > >> > during component build or activatoin time itself? > > >> > > > >> > OPTION 2: I believe this whole thing can be solved if we can simply > > >> check > > >> > in > > >> > the binding if the interface is marked remote. > > >> > > > >> > OPTION 3: Currently DataBindingRuntimeWireProcessor.process() method > > >> > checks > > >> > if the source and target interfaces is remotable before it validates > > to > > >> > see > > >> > if data transformation is required. One way of solution to throw a > > >> warning > > >> > msg is to check the source and target datatypes, if their datatypes > > are > > >> > diff > > >> > we assume that data transformation is required and we look if the > > >> > interfaces > > >> > are marked remotable, if not we throw a warning msg to alert that > > there > > >> > could be an unexpected behaviour in data transformation. > > >> > > > >> > OPTION 4: In the DataBindingRuntimeWireProcessor.process() method, > > just > > >> > check if the source and target interface is remotable OR if the > > source > > >> and > > >> > target datatypes are different. If any one condition is satisfied > > then > > >> we > > >> > assume that data transformation is required. > > >> > > > >> > Apart from the above mentioned issue, do we need to make such checks > > for > > >> > ws > > >> > binding as well OR do we need this checks for all kind of bindings. > > Like > > >> > to > > >> > know people's view on this regard. Thanks. > > >> > > > >> > -- > > >> > Thanks & Regards, > > >> > Ramkumar Ramalingam > > >> > > > >> > > >> Hi Ramkumar > > >> > > >> When I originally raised the JIRA I had imagined the solution would be > > >> your > > >> OPTION 1. So that we get a warning that at least tells the user that > > they > > >> are doing something odd. In my case it took me a while to work out > what > > >> the > > >> problem was so it would have been nice if the runtime had at least > said > > >> "you > > >> are dong something strange are you sure you want to do this". > > >> > > >> I hadn't imagines that we could introduce a data transformation in > this > > >> case. Is there code in there that tries and optimizes away the remote > > >> binding if it detects that the components are running locally? > > >> > > >> Simon > > >> > > > > > > Hi Simon, > > > I believe, we don't do any validatation to identify if the component is > > > local / remote. But anyway we assume that the component is remote by > > > checking if the interface is remotable. I could see that we only check > > if > > > the interfaces are remotable and we try to apply appropriate binding > and > > > data transformation upon them. > > > > > > I agree with your idea of identifying the component as local/remote and > > do > > > some optimization on binding and data transformation part. If everyone > > > agrees that we need this in place we can probably think of taking this > > > suggestion forward. > > > > > > -- > > > Thanks & Regards, > > > Ramkumar Ramalingam > > > > > > > Hi Simon, > > In the mean time, while leaving the optimization part. To fix the issue > > mentioned in TUSCANY-1881, i believe the best solution would be to > > identify > > at the bindingProvider level (except for binding.sca) to check if the > > source > > and target interface is remotable and throw a warning message as > required. > > > > Hope this helps. > > > > -- > > Thanks & Regards, > > Ramkumar Ramalingam > > > > Sounds good to me. > > Simon >
Hi Simon, In case of JSON-RPC binding (our original scenario), when the interface is not defined @Remotable the runtime just ignores the data transformation between the binding without throwing any exception. But I have noticed that in case of Axis2 binding for the same scenario, we get an exception as shown below. *java.lang.IllegalArgumentException*: Can't handle *mixed* payloads between OMElements and other types. I believe, just throwing a warning would not help for all kind of bindings.... as such scenario could even throw runtime exceptions sometimes. Not sure how to handle such scenarios. Please suggest. -- Thanks & Regards, Ramkumar Ramalingam
