Hi Jeremy, Is what you have written out here captured somewhere. I wish we could do that on the Wiki. I went there to do it, but could not Edit.
We must have page on Tuscany Architecture and Design and what you have mentioned here I would like to put under a sub-heading called 'Tuscany Extensions' under that. So that you don't have to repeat these things yet another time in the future or you might utmost pass the link. Right now there is one page http://wiki.apache.org/ws/Tuscany/TuscanyJava/Extending for this, but that might need some updates. By the way there is SDO Java, DAS Java overviews... but no SCA Overview. We need to get that in place as well. One of the things that we can put as part of the SCA Overview page is about running the samples i.e about how you extract the distribution and start the JVM with -jar bin/launcher.jar and so on. If somebody can help me with Edit permissions I am most willing to start with this myself :-) Thanks - Venkat On 8/3/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Aug 3, 2006, at 7:49 AM, Yang Lei (JIRA) wrote: > Need a extendable way to register SCDL loaders > ---------------------------------------------- > > Key: TUSCANY-593 > URL: http://issues.apache.org/jira/browse/TUSCANY-593 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core > Affects Versions: Java-M1 > Environment: windows XP > Reporter: Yang Lei > > > Please let me know if Tuscany offers extendable way to register > SCDL loaders , so we can always use the root of the loader such as > ModuleLoader to load a SCDL without manually register each > individual loader. The problem with this approach is if some one > add an extension to the SCDL, we also needs to know the new loader... Our modularity story is based on people being able to provide extensions that are complete in themselves. For example, someone would provide an extension for a new implementation type (like JavaScript) or a new binding (like RMI). Each extension hooks into the runtime at three points: 1) a loader that handles extension-specific XML elements 2) a builder that creates extension-specific components 3) the runtime components that hook into the wiring fabric Each extension is packaged as a composite which can be <included> in another or which can be deployed into the system. When the composite starts, all the components it contains register themselves with the appropriate registries in the runtime (e.g. the LoaderRegistry). How each extension is registered is determined by the host environment. In M1 this was done by adding system.fragment definitions to the classpath; in trunk this is done through extension components such as the DirectoryScanExtender. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
