On Thu, Sep 3, 2009 at 11:27 AM, Ramkumar R<[email protected]> wrote: > On Thu, Sep 3, 2009 at 1:24 PM, ant elder <[email protected]> wrote: >> >> On Wed, Sep 2, 2009 at 1:02 PM, Simon Laws<[email protected]> >> wrote: >> >> I was having thinking about backward compatibility again and wonder if >> >> there is another approach we've not mentioned yet which may be easier >> >> - translate OSOA contributions to OASIS at runtime. At the simplest >> >> level all that needs to be done is change the namespace in XML files >> >> (eg in getName in the XMLStreamReader) and change the annotation >> >> package name in Java implementation classes (eg using ASM in >> >> BaseJavaImplementationImpl.setJavaClass), just those two changes would >> >> get a lot of the 1.x samples running in 2.x, and with a bit more work >> >> would be to do more complex transformations of composites to map >> >> between OSOA and OASIS. There are some things we can't support, such >> >> as conversations, but we should be able to get a lot of 1.x >> >> contributions running on the 2.x runtime with that approach. >> >> >> >> WDYT, is this something worth having a go at? >> >> >> >> ...ant >> >> >> > >> > I think Mark discussed this approach originally under the title of a >> > migration tool. Given that we currently support OSOA and OASIS >> > composites using separate runtimes then a migration tool would be >> > useful. However I don't agree with the "at runtime" part. If we build >> > a migration tool I think it should be under the control of the user as >> > to when it runs. If they have a 1.0 composite then they can convert it >> > to a 1.1 composite, take notice of any errors that are reported during >> > the conversion and, once happy, run it on the 1.1 runtime. No magic >> > required. >> > >> > Simon >> > >> >> Ok if we have a tool approach then it will be easy enough to have it >> work ine either batch or runtime and share the code. >> >> I guess an obvious way to start would be trying to use XSLT to >> transform OSOA composites and contribution xml into OASIS ones and >> seeing what things that comes across which can't be migrated with a >> simple transform. >> >> ...ant > > Using an XSLT transformation looks like good migration tool > for me. But that's only good enough for the composite file transformation, > we need a method to handle the annotations used in the code? > > -- > Thanks & Regards, > Ramkumar Ramalingam >
Yep, so along with the XSLT transormation the application code needs to get updated to use the OASIS APIs and annotations. As Simon suggested an offline tool could use awk on the Java files, or a runtime tool could use Asm on the class files, to fix the annotaions as its mostly just a package rename. There are also the varrious SCA and Tuscany APIs though which are a little more complicated, for them it might be easiest to include some backward compatible facade classes that transform the OSOA/1.x clalls to use the OSOA/2.x API. Wont be able to get everything to work but those will be less common edge cases and it looks like we should be able to get quite a high percentage of old contributions working. ...ant
