On Sep 5, 2006, at 3:20 PM, Chris Wall wrote:

A few questions not necessarily related to the plugin, but to Tuscany webapps in general:

1.) The plugin doesn't define an application scdl location. I think the default is WEB-INF/default.scdl and applicationScdlPath allows for flexibility. But, what is recommended in the context of Tuscany structure (WEB-INF/tuscany)? Or is this structure strictly is for runtime stuff only? Should the plugin create a META-INF/ tuscany structure? Could the plugin be application scdl aware and move the scdl to a common location?

I think this raises a fairly fundamental question about what the "default" composite is. The Java C&I spec says that there is such a composite but does not say where the SCDL is define nor where its implementations are loaded from. Personally, I think that having a "default" composite is a problem but I haven't managed to get the spec people to buy into that.

If we assume that all the code has to be on the webapp classpath then all we need to know is the location of the scdl for that "default" composite and in that case isn't WEB-INF/default.scdl a reasonable location?

2.) Along the lines of #1, where should extension scdls be placed? And how should the main webapp scdl reference these extension scdls. I've been hacking webapp.system.scdl with <include.../> references. Obviously this isn't friendly and invasive to Tuscany's core. Could Tuscany append scdls located in a specific location (WEB-INF/tuscany/extensions/scdl) or query the classpath or?

I was envisioning extension scdls would be packaged in the extension's jar (making it a composite jar) and that jar would be placed in WEB-INF/tuscany/extension by the plugin. There would be an extender in the webapp-host system scdl that would scan that webapp resource (like the DirectoryScanExtender but using ServletContext.getResourcePaths() instead of File.listFiles()). The extension "directory" could also contain bare XML files (with any code being located through <dependency> elements in the XML).


3.) What exactly does Tuscany need in a web.xml - context-params, listeners, filters, etc? I've seen as little as the TuscanyContextListener and systemScdlPath and applicationScdlPath and as much as the following:

I think we may need all of this (now snipped but you get the idea):
* the context listener to start the runtime
* the filter to bind the "default" context to the thread
* the servlet to dispatch inbound service requests

I also think the number of things is confusing and would like it if the plugin added them :-)
--
Jeremy



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to