Hi Jeremy, you probably missed the mail just before. I managed to do it and have some content up the wiki already. Thanks anyways.
- Venkat On 8/4/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
You should be able to edit if you have an account. There should be a Login link near the top right (or click here http:// wiki.apache.org/ws/UserPreferences), enter name password and email and CreateProfile - you should be good to go. - Jeremy On Aug 4, 2006, at 1:04 AM, Venkata Krishnan wrote: > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
