This hasn't shown up on this list...sending again
Begin forwarded message:
From: Jim Marino <[EMAIL PROTECTED]>
Date: September 1, 2006 10:16:06 AM PDT
To: tuscany-dev@ws.apache.org
Subject: Re: Avoiding extension and application scdl collisions
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: <tuscany-dev@ws.apache.org>
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: <tuscany-dev@ws.apache.org>
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: <tuscany-dev@ws.apache.org>
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" <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: tuscany-dev-
[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]