I am yet to try this out but then from what I read, this sounds good and useful as it would determine how fast we can bring up the runtime.
Thanks for doing this :) - Venkat On 6/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote: > > There has been many commits and good progress the last few days, so I > spent a little bit of time checking the status of the trunk. > > Here's a summary of what I found: > - The code cleanup is almost complete, I think there's a little bit > work left to refactor one last .spi. package, remove a few dead > classes, also it looks like Raymond has started to clean up the Scope > registry and WorkContext I'm not sure if it's finished or not. > - The Java, Script and RMI extensions are now stable, as well as the > sample implementation, binding, and data binding extensions. > - It looks like we have a reasonable Web app story with a servlet > context listener, but it may require a little bit of cleanup to avoid > confusion with sca-contribution.xml. I'm also not sure if it allows to > expose Web Services from a Web app, or if we even want to do that now. > > Main todo's that I could think of: > - Port the Web Service binding extension to the latest code, as it's > really important to have, and is also used by many integration tests. > - Run RAT and check licenses and notices. > - Check why the itest/spec-api test cases are failing. > - Create a JAR containing the source of our runtime, to help debugging > in an IDE. > - Are the samples build.xml finished? > - I have ported the Spring extension to the latest code but need to do > a little bit of cleanup tomorrow before committing it. > - I'm not sure about the JSONRPC binding, wouldn't it be nice to have > it too? > - Lazy loading of our modules to avoid loading too many dependencies > when using tuscany-sca-all.jar. > - Rename the packages to *.sca.* but I would suggest to delay this to > a later point some time next week after our first RC. > > And there's probably a few more :) > 0.91 is around the corner and I finally found some time to tackle the "Lazy loading of modules" issue mentioned in this thread. The 0.90 release code was pretty aggressive with loading all Tuscany extension modules on the classpath. This can be optimized now. With the changes I have committed today (r549339) an extension does not have to register a ModuleActivator anymore (it can still do it but does not have to). Instead you can declare your Tuscany extension's ArtifactProcessors and ProviderFactories individually, still using the same META-INF/services mechanism, but allowing you to specify additional metadata when you declare them, like the QName of the XML element and the name of the model class you're handling. If you do that, then you'll give the Tuscany runtime enough information to allow it to load your classes dynamically, when your particular implementation or binding extension is hit in an SCA assembly. If your extension is not used in your application, it will not be loaded at all. I have committed new extension samples that show how to use this improved declaration mechanism: samples/implementation-crud2-extension samples/binding-echo2-extension samples/implementation-pojo2-extension File META_INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor registers an artifact processor syntax: <artifact processor class name>;type=<XML element namespace>#<element name>,model=<model class name> File META_INF/services/services/org.apache.tuscany.sca.provider.ImplementationProviderFactory registers an implementation provider factory syntax: <factory class name>;model=<model class name> File META_INF/services/services/org.apache.tuscany.sca.provider.BindingProviderFactory registers a binding provider factory syntax: <factory class name>;model=<model class name> If people find this new capability useful I can help merge the code into the 0.91 branch. The changes are mainly new Lazy*Something classes and a little more code in the host-embedded runtime bootstrapping. -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
