On Sep 1, 2006, at 9:22 AM, Raymond Feng wrote:
Hi,
Where do we stand for this topic?
Here are some questions to be confirmed:
1) Should we allow system/extension/application code on the same
classpath even it's not the best pratice? If not, should we get rid
of the "SCATestCase"?
We should not allow this for *end-user* applications. I have less of
a problem with SCATestCase (we could perhaps improve it not to cram
stuff on the classpath) for use in quick prototyping of extensions as
part of an SDK. There is absolutely no need, however, to use
SCATestCase for unit testing of extensions or end-user applications.
2) Should we have different SCDL file naming conventions for
systems, extensions and applications?
Don't know. What do you propose?
3) Should we use ClassLoader.getResource() to locate SCDL files?
I don't like that. I'd prefer to have SCDLs files in well-defined
locations.
4) How do we support extension dependencies in the following cases?
* An extenasion depends on a 3rd party jar
* An extension depends on another extension
This would be done using a multiparent classloader and calculating
the transitive closure of dependencies. We have at least two options
here. As Jeremy proposed, use Maven syntax to define dependencies.
The advantages here are that it works, most open source projects have
been Mavenized so we get third-party dependency tracking for free,
and the ability to have ArtifactFactory implementations download from
remote Maven repos. We can also use OSGi. Benefits are we get a
"standard" way to handle classloader isolation. This will mean,
however, taking a dependency on an OSGi container and having bundles
for all extension and their third-party libraries. A third option is
to have both: use OSGi has a host container and Tuscany core as a
bindle. OSGi and Tuscany services could be wired through the OSGi
binding. Joel was working on this.
Do you want to submit a proposal so we can discuss further?
5) Do we have any plan to fully leverage OSGi to deal with bundle
isolations and dependencies?
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, August 25, 2006 11:37 AM
Subject: Re: Avoiding extension and application scdl collisions
On Aug 25, 2006, at 10:56 AM, Raymond Feng wrote:
Please see more comments below.
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, August 25, 2006 10:27 AM
Subject: Re: Avoiding extension and application scdl collisions
On Aug 25, 2006, at 9:32 AM, Raymond Feng wrote:
Hi,
It's a bit challenging to run a simple SCA J2SE helloworld
sample. Here's the folder structure you have to deal:
helloworld
--- bin: the launcher.jar, sca-api.jar and host-util.jar
--- boot: core.jar, spi.jar, etc
--- extension: axis2.jar (optional)
helloworld.jar
Then you can use the launcher to run helloworld sample.
I fully understand the value of isolation for different level
of code. I just have a feeling maybe it's too much for a poor
J2SE user to get the basic sample working.
Ah so this is referring to J2SE client (i.e. from main) and not
in a managed environment. I still think this is not that big
of a deal. I personally prefer to have directories where I
can stick things than a huge classpath. It also avoids the
pain of package collisions with application code. Embedded
Jetty works like this and I've found it pretty straightforward.
I'm not against the isolation which is definitely required for a
managed environment. I also agree with you that a huge classpath
is not the best pratice even for J2SE. I just wonder if it's
still possible for a dummy user to choose one single classpath
to include everything.
I think we should help the "dummy" user get their setup correct.
People will also still have to deal with SCDL anyway and that
should be in a well-defined location. Having extensions in a
well- defined location does not seem to be an additional burden.
I'm seeing inconsistency in some places that we still use
ClassLoader.getResource() to resolve URLs which seems to me that
it violates the idea of "isolation by location". For example, we
use ClassLoader.getResource("META-INF/tusacny/system.scdl") for
the core and ClassLoader.getResource("META-INF/sca/
default.scdl") for the application.
We should fix that inconsistency.
More importantly, if we are trying to make the use case of a
single reference used by a J2SE client easier, I'd would say
don't use SCA for that. Just use Axis (or some other
transport) directly. Where SCA is valuable is in assembly of
multiple services.
I'm not sure :-) I think it should also be possible for these
guys to take advantage of SCA (I assume SCA can simplify
programming).
SCA doesn't simplify all programming. Sometimes it's just easier
to avoid the unnecessary overhead of "frameworks".
I have some related questions here:
1) Is it possible to use SCA with Tuscany inside a traditional
J2SE application with a flat classpath?
Can you give a more detailed use case? If it is just accessing
one service, or a couple, then my answer would probably be the
same as above: use the transport directly, it will always be
much easier. If you want to have an application with one SCA
service in it wired to others, then a container needs to be
deployed and it is not an "J2SE application" anymore, it is an
"SCA application running in a J2SE host".
I was thinking about adding SCA capability into an existing J2SE
app.
For me, the use case here would be wiring to or from a service in
an existing app. This is one of the main uses cases for Spring
(and EJB, etc.). The way I would do this is not through a J2SE
client but by including the application in a composite and using
composite services or references to wire to and from children in
the application.
2) Where should the dependency jars go? It includes the
dependency jars for core runtime and extensions.
I'm not sure I follow, what is "it"?
For example, our Axis2 bining has dependencies on Axis2 jars and
our core has dependencies on StAX. Where should these jars go?
It depends. Generally, I would isolate the StAX dependency between
extensions since they may depend on a different version.
3) Can I have one extension depend on another extension?
Sure, in which case we need to calculate the transitive closure
of all dependencies and adjust classpaths accordingly. OSGi
will do this for us.
I like OSGi too. Why don't we leverage OSGi in the core instead
of reinventing the wheels?
I agree with you here if OSGi gives us what we need (and hopefully
it does).
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, August 25, 2006 8:59 AM
Subject: Re: Avoiding extension and application scdl collisions
On Aug 24, 2006, at 10:50 PM, 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.
Could you explain your reasons why? The only case where I can
see this being a good thing for the user is if an extension
offers APIs or libraries that must be accessed from the
application. In that case, those APIs or libraries should be
loaded in a parent to the extension classloader which is
then given as a parent to the application classloader (which
would be multiparent).
Jim
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" <[email protected]>
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]
------------------------------------------------------------------
-- -
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]
---------------------------------------------------------------------
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]
