I'd still prefer to have extensions and system referenced from a different
directory. Does the spec really mandate the file extension; I kind of preferred
scdl myself
Raymond Feng wrote:
Hi,
I understand we endeavor to support isolated classloading for system,
extension, and application. But I think we should be able to run a SCA
application with the runtime and extension jars on its classpath if the
user chooses to do so.
To be consistent with the SCA spec (xxx.composite), I suggest that we
have the following conventions.
core: META-INF/tuscany/system.composite (with includes)
extension: META-INF/tuscany/extension.composite
application: META-INF/sca/application.composite
Thanks,
Raymond
----- Original Message ----- From: "Rick" <[EMAIL PROTECTED]>
To: "tuscdev" <tuscany-dev@ws.apache.org>
Sent: Thursday, August 24, 2006 9:26 AM
Subject: Avoiding extension and application scdl collisions
I kind of have and closer idea why interop unit testcases fail when
run from the maven command line. It appears the forking for some
reason I'm still not 100% sure of puts the Axis2Binding jar in the
same classloader as the application scdl. It could be the fork
actually has dependencies need by the testcase already on the
classpath? In any case when the application scdl is being search for
it is being found in the extension jar because the default resource
name is the same for both extensions and application scdl
(META-INF/sca/default.scdl) I can for the testcase specifically rename
the application scdl to something different and it then works. To
avoid this and also provide the flexibility to load in one classloader
scope would having default names as follows be reasonable?:
META-INF/tuscany/system/system.scdl. (system)
META-INF/tuscany/extension/default.scdl (extensions)
META-INF/sca/default.scdl (application)
(not too sure how this plays with the SCA archive proposal)
Also, I'm wondering if it is already possible, if we could add an xml
attribute to system and extension scdl to identify it as such so when
we are expecting one type and it does not have this attribute we throw
an exception? This would have been a whole lot more helpful to me
than the resulting NPE?
Thought?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
