Also what got lost in the conversation, I brought up if there isn't some how we
could differentiate system, extension and application scdl ? If necessary, add
some attribute? So when we're loading and expecting one type and receive
another we throw an meaningfully exception?
Jim Marino wrote:
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: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
