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"?
2) Should we have different SCDL file naming conventions for systems,
extensions and applications?
3) Should we use ClassLoader.getResource() to locate SCDL files?
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
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]
