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]