You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2006/07/28 14:13:25 UTC
How to use extensions with the standalone launcher?
I'm trying to get some standalone JavaScript samples working but I'm not
sure how the javascript container jar is supposed to be used with the
launcher. Is there a special place I need to put the jar, or a parameter to
use to tell the launcher where the jar is?
...ant
Re: Composite classpaths, was: How to use extensions with the standalone launcher?
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 31, 2006, at 11:42 PM, Jim Marino wrote:
> An end user application developer could write some type of library
> that gets reused by different composites. We should have a
> mechanism that supports this without resorting to maven. I think we
> should have some type of resolver abstraction, one implementation
> being a maven downloader.
I agree.
We need an abstraction for "dependent artifact" and a way of locating
and resolving them; using a Maven repository would be one concrete
implementation of that abstraction.
>>> There are a couple of other options we could also provide, based
>>> off of OSGi semantics:
>>>
>>> 1. Allow a jar to specify its dependencies using "pure" OSGi
>>> manifest entries when the composite is packaged as a bundle and
>>> deployed to an OSGI environment
>>> 2. Allow the SCDL to specify dependencies using OSGI semantics.
>>> These would then be "baked" down to whatever packaging the host
>>> environment supported, perhaps through a pre-deploy step
>>> 3.As part of #2, have a way to specify a maven bundle and have
>>> the pre-deployer pul it from maven and repackage it.
>>>
>>> Generally I don't like pre-packagers but that may be the price
>>> people have to pay for deploying on host environments with
>>> problematic classloading semantics - e.g. J2EE app servers. In an
>>> OSGi or jar launcher environment, things should just work without
>>> a predeploy step.
>>
>> These seem like alternatives. If the user wants to use OSGi
>> semantics then this would be a way to support them. However, there
>> are a lot of things out there that do not have OSGi manifests and
>> we need to be able to support them two.
>>
> That's what #2 would be used for as it is not dependent on OSGi
> artifacts such as bundles. A SCDL artifact would specify the
> dependencies and they could be resolved to whatever physical
> packaging the host platform supports/
This seems like it can be implemented on top of a repository for OSGi
artifacts or a repository of Maven artifacts - this sounds good.
>
>> Also, these only work if the composite is packaged as a bundle and
>> I think that it's important to allow people to deploy composites
>> that are simple XML SCDL files (no archive involved). That means
>> we need a way in the SCDL to be able to specify what the
>> dependencies are.
>>
> #2 could also work with a file system through some type of "custom
> resolver" mentioned above.
So the key here is the abstraction for artifact resolution. The
interface I had proposed before was:
interface CompositeRepository {
URL locate(String name);
URL locate(String groupId, String artifactId, String version,
String identifier);
}
We probably need to extend this to capture the formal concept of an
Artifact so I would recast this as:
class Artifact {
String group; // a conceptual grouping of artifacts such
as publisher
String name; // the name of the artifact
String version; // the version of the artifact
String classifier; // a classifier such as hardware platform or
language
boolean optional; // whether the artifact is required
}
class ResolvedArtifact extends Artifact {
URL url; // a URL where the artifact can be obtained
(typically a file: URL)
Collection<ResolvedArtifact> dependencies; // list of
dependencies the artifact has
}
interface ArtifactRepository {
ResolvedArtifact resolve(String name); // lookup based on a
simple string supplied by the user
ResolvedArtifact resolve(Artifact artifact); // lookup based on
explicit information
}
I think this is general enough to cover both Maven and OSGi artifact
naming schemes (and hopefully more).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Composite classpaths, was: How to use extensions with the standalone launcher?
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 31, 2006, at 1:56 PM, Jeremy Boynes wrote:
> On Jul 30, 2006, at 6:33 PM, Jim Marino wrote:
>
>>
>> On Jul 30, 2006, at 5:21 PM, Jeremy Boynes wrote:
>>
>>> On Jul 30, 2006, at 2:55 PM, ant elder wrote:
>>>
>>>> What about the dependencies of the extension? It looks like
>>>> right now all
>>>> the dependency jars still have to go in the boot directory and
>>>> only the
>>>> extension in the extension directory. Is that what you intend?
>>>
>>> The spec does not define way to specify the classpath for a
>>> composite so for now everything has to be bundled in it on in a
>>> parent classloader (and the boot classloader is the parent to the
>>> each of the extension composites).
>>>
>>> The jar classpath will still work so if you provide a Class-Path
>>> entry in the manifest dependencies specified there should be found.
>>>
>>> Longer term I think we need a way to define a classpath in the
>>> composite. I had a quick discussion a while ago with Oisin about
>>> using a Maven repository to hold SCA artifacts and perhaps we can
>>> use that here. I can think of two ways we could allow users to do
>>> this:
>>>
>> For system services I think this is fine but I wouldn't want to
>> require this of applications.
>
> I don't see the distinction here. We are saying that system
> services are just composites and this is a way of associating
> resources with a composite (specifically Java class files) - why
> would there be any difference?
>
An end user application developer could write some type of library
that gets reused by different composites. We should have a mechanism
that supports this without resorting to maven. I think we should have
some type of resolver abstraction, one implementation being a maven
downloader.
>> There are a couple of other options we could also provide, based
>> off of OSGi semantics:
>>
>> 1. Allow a jar to specify its dependencies using "pure" OSGi
>> manifest entries when the composite is packaged as a bundle and
>> deployed to an OSGI environment
>> 2. Allow the SCDL to specify dependencies using OSGI semantics.
>> These would then be "baked" down to whatever packaging the host
>> environment supported, perhaps through a pre-deploy step
>> 3.As part of #2, have a way to specify a maven bundle and have the
>> pre-deployer pul it from maven and repackage it.
>>
>> Generally I don't like pre-packagers but that may be the price
>> people have to pay for deploying on host environments with
>> problematic classloading semantics - e.g. J2EE app servers. In an
>> OSGi or jar launcher environment, things should just work without
>> a predeploy step.
>
> These seem like alternatives. If the user wants to use OSGi
> semantics then this would be a way to support them. However, there
> are a lot of things out there that do not have OSGi manifests and
> we need to be able to support them two.
>
That's what #2 would be used for as it is not dependent on OSGi
artifacts such as bundles. A SCDL artifact would specify the
dependencies and they could be resolved to whatever physical
packaging the host platform supports/
> Also, these only work if the composite is packaged as a bundle and
> I think that it's important to allow people to deploy composites
> that are simple XML SCDL files (no archive involved). That means we
> need a way in the SCDL to be able to specify what the dependencies
> are.
>
#2 could also work with a file system through some type of "custom
resolver" mentioned above.
Jim
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Composite classpaths, was: How to use extensions with the standalone launcher?
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 30, 2006, at 6:33 PM, Jim Marino wrote:
>
> On Jul 30, 2006, at 5:21 PM, Jeremy Boynes wrote:
>
>> On Jul 30, 2006, at 2:55 PM, ant elder wrote:
>>
>>> What about the dependencies of the extension? It looks like right
>>> now all
>>> the dependency jars still have to go in the boot directory and
>>> only the
>>> extension in the extension directory. Is that what you intend?
>>
>> The spec does not define way to specify the classpath for a
>> composite so for now everything has to be bundled in it on in a
>> parent classloader (and the boot classloader is the parent to the
>> each of the extension composites).
>>
>> The jar classpath will still work so if you provide a Class-Path
>> entry in the manifest dependencies specified there should be found.
>>
>> Longer term I think we need a way to define a classpath in the
>> composite. I had a quick discussion a while ago with Oisin about
>> using a Maven repository to hold SCA artifacts and perhaps we can
>> use that here. I can think of two ways we could allow users to do
>> this:
>>
> For system services I think this is fine but I wouldn't want to
> require this of applications.
I don't see the distinction here. We are saying that system services
are just composites and this is a way of associating resources with a
composite (specifically Java class files) - why would there be any
difference?
> There are a couple of other options we could also provide, based
> off of OSGi semantics:
>
> 1. Allow a jar to specify its dependencies using "pure" OSGi
> manifest entries when the composite is packaged as a bundle and
> deployed to an OSGI environment
> 2. Allow the SCDL to specify dependencies using OSGI semantics.
> These would then be "baked" down to whatever packaging the host
> environment supported, perhaps through a pre-deploy step
> 3.As part of #2, have a way to specify a maven bundle and have the
> pre-deployer pul it from maven and repackage it.
>
> Generally I don't like pre-packagers but that may be the price
> people have to pay for deploying on host environments with
> problematic classloading semantics - e.g. J2EE app servers. In an
> OSGi or jar launcher environment, things should just work without a
> predeploy step.
These seem like alternatives. If the user wants to use OSGi semantics
then this would be a way to support them. However, there are a lot of
things out there that do not have OSGi manifests and we need to be
able to support them two.
Also, these only work if the composite is packaged as a bundle and I
think that it's important to allow people to deploy composites that
are simple XML SCDL files (no archive involved). That means we need a
way in the SCDL to be able to specify what the dependencies are.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Composite classpaths, was: How to use extensions with the standalone launcher?
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 30, 2006, at 5:21 PM, Jeremy Boynes wrote:
> On Jul 30, 2006, at 2:55 PM, ant elder wrote:
>
>> What about the dependencies of the extension? It looks like right
>> now all
>> the dependency jars still have to go in the boot directory and
>> only the
>> extension in the extension directory. Is that what you intend?
>
> The spec does not define way to specify the classpath for a
> composite so for now everything has to be bundled in it on in a
> parent classloader (and the boot classloader is the parent to the
> each of the extension composites).
>
> The jar classpath will still work so if you provide a Class-Path
> entry in the manifest dependencies specified there should be found.
>
> Longer term I think we need a way to define a classpath in the
> composite. I had a quick discussion a while ago with Oisin about
> using a Maven repository to hold SCA artifacts and perhaps we can
> use that here. I can think of two ways we could allow users to do
> this:
>
For system services I think this is fine but I wouldn't want to
require this of applications. There are a couple of other options we
could also provide, based off of OSGi semantics:
1. Allow a jar to specify its dependencies using "pure" OSGi manifest
entries when the composite is packaged as a bundle and deployed to an
OSGI environment
2. Allow the SCDL to specify dependencies using OSGI semantics. These
would then be "baked" down to whatever packaging the host environment
supported, perhaps through a pre-deploy step
3.As part of #2, have a way to specify a maven bundle and have the
pre-deployer pul it from maven and repackage it.
Generally I don't like pre-packagers but that may be the price people
have to pay for deploying on host environments with problematic
classloading semantics - e.g. J2EE app servers. In an OSGi or jar
launcher environment, things should just work without a predeploy step.
Jim
> 1) if the composite is provided as a jar file, look in the jar file
> for Maven metadata stored in META-INF/maven/${groupId}/$
> {artifactId}/pom.xml and read the dependencies from there.
>
> 2) allow the user to specify a <dependencies> element in the SCDL
> file listing artifacts to be added to the classpath
>
> We take the list of dependencies, obtain them from a maven repo and
> add them to the classpath for the composite. This would work for
> any composite not just ones used as extensions.
>
> Does that seem like it would work?
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Composite classpaths, was: How to use extensions with the standalone launcher?
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 30, 2006, at 2:55 PM, ant elder wrote:
> What about the dependencies of the extension? It looks like right
> now all
> the dependency jars still have to go in the boot directory and only
> the
> extension in the extension directory. Is that what you intend?
The spec does not define way to specify the classpath for a composite
so for now everything has to be bundled in it on in a parent
classloader (and the boot classloader is the parent to the each of
the extension composites).
The jar classpath will still work so if you provide a Class-Path
entry in the manifest dependencies specified there should be found.
Longer term I think we need a way to define a classpath in the
composite. I had a quick discussion a while ago with Oisin about
using a Maven repository to hold SCA artifacts and perhaps we can use
that here. I can think of two ways we could allow users to do this:
1) if the composite is provided as a jar file, look in the jar file
for Maven metadata stored in META-INF/maven/${groupId}/${artifactId}/
pom.xml and read the dependencies from there.
2) allow the user to specify a <dependencies> element in the SCDL
file listing artifacts to be added to the classpath
We take the list of dependencies, obtain them from a maven repo and
add them to the classpath for the composite. This would work for any
composite not just ones used as extensions.
Does that seem like it would work?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to use extensions with the standalone launcher?
Posted by ant elder <an...@gmail.com>.
What about the dependencies of the extension? It looks like right now all
the dependency jars still have to go in the boot directory and only the
extension in the extension directory. Is that what you intend?
...ant
On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> The launcher scans a directory called "extensions" under the root and
> deploys everything it finds there as a child to the system composite -
> just dropping a jar containing a "default.scdl" in there should add it
> in.
>
> We should write this up better but here's the original post to the list:
>
> http://article.gmane.org/gmane.comp.apache.webservices.tuscany.devel/4980/match=extension
>
> --
> Jeremy
>
> On 7/28/06, ant elder <an...@gmail.com> wrote:
> > I'm trying to get some standalone JavaScript samples working but I'm not
> > sure how the javascript container jar is supposed to be used with the
> > launcher. Is there a special place I need to put the jar, or a
> parameter to
> > use to tell the launcher where the jar is?
> >
> > ...ant
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: How to use extensions with the standalone launcher?
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 3, 2006, at 1:16 AM, Ken Tam wrote:
>> > How about pushing extension handling down into the Launcher so that
>> > all hosts using that will pick up that functionality? It should
>> > scan/deploy extensions at runtime boot-time, plus expose APIs so
>> that
>> > extensions can be deployed dynamically after boot (e.g. the host
>> might
>> > file-watch a directory for new JARs).
>>
>> I don't know that the Launcher should do that - I think it's job is
>> just to bring up the runtime.
>>
>> I would suggest enhancing the DirectoryScanExtender so that it could
>> do periodic scans and a host can enable/disable it using appropriate
>> system SCDL.
>
> Didn't know about the DSE (blew right by that earlier mail thread
> where you brought it up), but after looking at it, yeah, agree. But
> since DSE is in core, I'd like to see extension deployment support
> exposed in SPI as well.
I had DSE as a standalone service (i.e. it has no service interface
and was just a component). I agree that if it had an interface then
that should be in SPI.
>> The APIs are already there - the DSE uses the Deployer API to add
>> composites and a host can do the same.
>
> Sort of -- the DSE uses classes like SystemCompositeComponent which
> come out of core, so in a world where core is CL-isolated, host
> environments (say, inside a webapp or junit) wouldn't be able to see
> those.
The reference to SystemCompositeComponent was unnecessary and I've
replaced it with a using a plain CompositeComponent (r428335). The
only core reference left is to SystemCompositeImplementation which is
necessary to deploy the extensions as system components.
>
> Put another way: if my junit/webapp listener only sees API & SPI (and
> not core), I don't see how they could deploy extensions today. Right
> now the webapp host expects core to be available, but we've already
> agreed that's undesirable.. ditto for the junit environment.
Yes but that sounds like the right thing to me. Extensions are part
of the runtime and in general we would not want application code to
have access to runtime artifacts like that. Put another way, you need
to be system code to deploy other system code.
One option would be to use Permissions to control this. We move
SystemCompositeImplementation into the API and have the deployer
implementation check different permissions when deploying application
vs. system components.
>
>> > My gut reaction is to agree that the naming convention for
>> extensions
>> > should not be the same as that for applications -- extensions are
>> > semantically part of the SCA runtime. So for now, the idea of
>> using
>> > e.g. extension.scdl for extensions rather than default.scdl
>> seems like
>> > a good first step (regardless of where we might evolve this in the
>> > future).
>>
>> Is that a fundamental difference or just a difference in how a
>> composite is used. I quite like that I can use an ordinary composite
>> (like the eagerinit one) as an extension just by including it in scdl
>> or by placing it in a directory.
>
> While I am not convinced that in actual usage it's going to be
> particularly useful to use "ordinary" composites as extensions, I'll
> admit that there's an elegance to it that I like. Per our earlier
> chat, if there's a short-term plan for improving extension loading
> (fixing some of the obvious existing issues) that allows us to keep
> the uniform use of default.scdl, I'm all for it -- but otherwise, I'm
> willing to see us switch filenames for awhile until that more
> extensive work can be done.
I don't see the problem here as lying with the extension mechanism
but with how the sample test cases are running.
They are basically trying to run the server inside Maven - this would
be comparable, for example, to booting an entire Tomcat or WebSphere
server in the test JVM for every test case you run. Worse, it is
being done by sticking the server's jars on the classpath rather than
running it in an environment where the configuration files etc. are
available.
This isn't going to work when we start adding functional tests that
require applications to be deployed to multiple servers or that
require network access. Instead we need a way for a test harness to
talk to a running server and deploy applications to it.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to use extensions with the standalone launcher?
Posted by Ken Tam <ke...@gmail.com>.
> > How about pushing extension handling down into the Launcher so that
> > all hosts using that will pick up that functionality? It should
> > scan/deploy extensions at runtime boot-time, plus expose APIs so that
> > extensions can be deployed dynamically after boot (e.g. the host might
> > file-watch a directory for new JARs).
>
> I don't know that the Launcher should do that - I think it's job is
> just to bring up the runtime.
>
> I would suggest enhancing the DirectoryScanExtender so that it could
> do periodic scans and a host can enable/disable it using appropriate
> system SCDL.
Didn't know about the DSE (blew right by that earlier mail thread
where you brought it up), but after looking at it, yeah, agree. But
since DSE is in core, I'd like to see extension deployment support
exposed in SPI as well.
> The APIs are already there - the DSE uses the Deployer API to add
> composites and a host can do the same.
Sort of -- the DSE uses classes like SystemCompositeComponent which
come out of core, so in a world where core is CL-isolated, host
environments (say, inside a webapp or junit) wouldn't be able to see
those.
Put another way: if my junit/webapp listener only sees API & SPI (and
not core), I don't see how they could deploy extensions today. Right
now the webapp host expects core to be available, but we've already
agreed that's undesirable.. ditto for the junit environment.
> > My gut reaction is to agree that the naming convention for extensions
> > should not be the same as that for applications -- extensions are
> > semantically part of the SCA runtime. So for now, the idea of using
> > e.g. extension.scdl for extensions rather than default.scdl seems like
> > a good first step (regardless of where we might evolve this in the
> > future).
>
> Is that a fundamental difference or just a difference in how a
> composite is used. I quite like that I can use an ordinary composite
> (like the eagerinit one) as an extension just by including it in scdl
> or by placing it in a directory.
While I am not convinced that in actual usage it's going to be
particularly useful to use "ordinary" composites as extensions, I'll
admit that there's an elegance to it that I like. Per our earlier
chat, if there's a short-term plan for improving extension loading
(fixing some of the obvious existing issues) that allows us to keep
the uniform use of default.scdl, I'm all for it -- but otherwise, I'm
willing to see us switch filenames for awhile until that more
extensive work can be done.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to use extensions with the standalone launcher?
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 2, 2006, at 2:18 PM, Ken Tam wrote:
> Some thoughts..
>
> How about pushing extension handling down into the Launcher so that
> all hosts using that will pick up that functionality? It should
> scan/deploy extensions at runtime boot-time, plus expose APIs so that
> extensions can be deployed dynamically after boot (e.g. the host might
> file-watch a directory for new JARs).
I don't know that the Launcher should do that - I think it's job is
just to bring up the runtime.
I would suggest enhancing the DirectoryScanExtender so that it could
do periodic scans and a host can enable/disable it using appropriate
system SCDL.
The APIs are already there - the DSE uses the Deployer API to add
composites and a host can do the same.
> My gut reaction is to agree that the naming convention for extensions
> should not be the same as that for applications -- extensions are
> semantically part of the SCA runtime. So for now, the idea of using
> e.g. extension.scdl for extensions rather than default.scdl seems like
> a good first step (regardless of where we might evolve this in the
> future).
Is that a fundamental difference or just a difference in how a
composite is used. I quite like that I can use an ordinary composite
(like the eagerinit one) as an extension just by including it in scdl
or by placing it in a directory.
>
> Jeremy: I concur with your statements about unit testing of components
> -- but note that ant's test case that started this whole discussion
> isn't really a "unit test" of the component logic but more of a
> functional test of the JavaScript extension. When new component types
> (which, like the JavaScript one, aren't Java based), it seems like
> we'd want to introduce an appropriate unit testing framework for that
> type.. ie, how does one unit test JS logic? (or Ruby, or ..).
I don't think we need to do anything to support unit testing - if
someone is writing JS or Ruby components then let them use whatever
unit test framework they want. What we need to be careful of is
making sure we don't make that hard.
What I think we do need is a functional test framework - something
that will let a developer deploy an entire application to a runtime
and test it in a way their users would hit it. For example, taking a
web application, deploy it and hit it with a framework like HTMLUnit
running against the webserver. Again, we're not building testing
tools; we would provide the glue that lets existing test tools work.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to use extensions with the standalone launcher?
Posted by Ken Tam <ke...@gmail.com>.
Some thoughts..
How about pushing extension handling down into the Launcher so that
all hosts using that will pick up that functionality? It should
scan/deploy extensions at runtime boot-time, plus expose APIs so that
extensions can be deployed dynamically after boot (e.g. the host might
file-watch a directory for new JARs).
My gut reaction is to agree that the naming convention for extensions
should not be the same as that for applications -- extensions are
semantically part of the SCA runtime. So for now, the idea of using
e.g. extension.scdl for extensions rather than default.scdl seems like
a good first step (regardless of where we might evolve this in the
future).
Jeremy: I concur with your statements about unit testing of components
-- but note that ant's test case that started this whole discussion
isn't really a "unit test" of the component logic but more of a
functional test of the JavaScript extension. When new component types
(which, like the JavaScript one, aren't Java based), it seems like
we'd want to introduce an appropriate unit testing framework for that
type.. ie, how does one unit test JS logic? (or Ruby, or ..).
On 8/1/06, ant elder <an...@gmail.com> wrote:
> How about until we have a way to do extensions properly to fix the problem
> Matthew is seeing the testcase could determine which is the application
> default.scdl by seeing if the resource URL starts with the current working
> directory which it can get from System.getProperty("user.dir")?
>
> ...ant
>
> On 8/1/06, Jeremy Boynes <jb...@apache.org> wrote:
> >
> > On Aug 1, 2006, at 11:28 AM, Matthew Sykes wrote:
> >
> > > FWIW, I think I've been running into a problem at build time
> > > because of this exact issue. There's a bit of code in the
> > > javascript sample HelloWorldTestCase.java test that gathers up all
> > > of the META-INF/sca/default.scdl resources it can find. The test
> > > then throws away the first resource in the enumeration assuming
> > > it's the application's default.scdl and not the extension's
> > > default.scdl.
> >
> > I think this is problematic - putting all the runtime code on the
> > application classpath is asking for trouble.
> >
> > > ant elder wrote:
> > >> I guess it somehow needs to find the URL to the default.scdl for the
> > >> JavaScript extension, but thats just in a jar on the classpath and
> > >> there's
> > >> lots of default.scdl resources on the class path so how does it
> > >> know which
> > >> is the JavaScript one?
> > >> And the once it has that URL it isn't real obvious (to me) how you
> > >> could use
> > >> that from the testcase to get the extension registered with the
> > >> runtime.
> > >> ...ant
> > >
> > > While the build generally succeeds, every once in a while the test
> > > fails with an UnrecognizedElementException on implementation.js. I
> > > added a System.out.println to the test to show which of the
> > > resources was thrown away in the following code snippet and found
> > > that the extension scdl can be discarded instead of the application
> > > scdl. (I'm assuming this is because enumeration that comes back
> > > from getResources doesn't have a specfied order.)
> > >
> > > At this point I guess I have to wonder if the name used for the
> > > extensions' scdl should be something different from the default
> > > application scdl name? It seems like it might be nice to do
> > > something like gather up like all of the visible META-INF/sca/
> > > extension.scdl resources and add them to the runtime as
> > > extensions. I don't believe this would be at odds with the current
> > > extensions mechanism in the DirectoryScanExtender if it went after
> > > extension.scdl instead of default.scdl.
> >
> > I don't think we want different types of composite for extensions and
> > other things.
> >
> > We're trying to add extensions into test cases without defining an
> > extension mechanism so it's not surprising things are not working
> > properly. Perhaps we should back up a little and think about what we
> > are trying to achieve.
> >
> > Putting a user hat on, here are the things that I would like to do:
> > 1) Unit test a component without needing any SCA runtime
> > infrastructure. I don't need Tuscany classes on the classpath to
> > compile my component and I don't want to pollute my test environment
> > with them. All I should need is my code and my test framework (for
> > example, TestNG).
> >
> > 2) Function test a component in the SCA runtime. I have installed and
> > configured Tuscany somewhere, adding in the extensions that I need. I
> > want to test code as if it was running in that environment. Ideally I
> > would like the runtime to boot quickly inside my test client but I
> > would also like to be able to deploy the component to an already
> > running environment.
> >
> > --
> > Jeremy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to use extensions with the standalone launcher?
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Jeremy,
Why not name them as extension.scdl. Though for most parts they might be
treated as any other scdl some where we treat them a little differently as
in adding them to extensions and so on. Infact a solution developer could
develop some extensions and applications and keep them all bundled
together. When deployed the SCA runtime is able to understand which ones
are application scdls and which ones are extensions scdls and treats them
accordingly. That way the SCA installation directories can be left alone
i.e. the user need not drop the extension jars in a predefined dir. and so
on.
Also am curious about the name 'default.scdl'. Why 'default'? Is it to
imply that these scdls will be automatically picked up and deployed? So can
I give other names to my scdls and if so is there a programming model to
explicitly mention about them or load them?
Thanks
- Venkat
On 8/2/06, ant elder <an...@gmail.com> wrote:
>
> How about until we have a way to do extensions properly to fix the problem
> Matthew is seeing the testcase could determine which is the application
> default.scdl by seeing if the resource URL starts with the current working
> directory which it can get from System.getProperty("user.dir")?
>
> ...ant
>
> On 8/1/06, Jeremy Boynes <jb...@apache.org> wrote:
> >
> > On Aug 1, 2006, at 11:28 AM, Matthew Sykes wrote:
> >
> > > FWIW, I think I've been running into a problem at build time
> > > because of this exact issue. There's a bit of code in the
> > > javascript sample HelloWorldTestCase.java test that gathers up all
> > > of the META-INF/sca/default.scdl resources it can find. The test
> > > then throws away the first resource in the enumeration assuming
> > > it's the application's default.scdl and not the extension's
> > > default.scdl.
> >
> > I think this is problematic - putting all the runtime code on the
> > application classpath is asking for trouble.
> >
> > > ant elder wrote:
> > >> I guess it somehow needs to find the URL to the default.scdl for the
> > >> JavaScript extension, but thats just in a jar on the classpath and
> > >> there's
> > >> lots of default.scdl resources on the class path so how does it
> > >> know which
> > >> is the JavaScript one?
> > >> And the once it has that URL it isn't real obvious (to me) how you
> > >> could use
> > >> that from the testcase to get the extension registered with the
> > >> runtime.
> > >> ...ant
> > >
> > > While the build generally succeeds, every once in a while the test
> > > fails with an UnrecognizedElementException on implementation.js. I
> > > added a System.out.println to the test to show which of the
> > > resources was thrown away in the following code snippet and found
> > > that the extension scdl can be discarded instead of the application
> > > scdl. (I'm assuming this is because enumeration that comes back
> > > from getResources doesn't have a specfied order.)
> > >
> > > At this point I guess I have to wonder if the name used for the
> > > extensions' scdl should be something different from the default
> > > application scdl name? It seems like it might be nice to do
> > > something like gather up like all of the visible META-INF/sca/
> > > extension.scdl resources and add them to the runtime as
> > > extensions. I don't believe this would be at odds with the current
> > > extensions mechanism in the DirectoryScanExtender if it went after
> > > extension.scdl instead of default.scdl.
> >
> > I don't think we want different types of composite for extensions and
> > other things.
> >
> > We're trying to add extensions into test cases without defining an
> > extension mechanism so it's not surprising things are not working
> > properly. Perhaps we should back up a little and think about what we
> > are trying to achieve.
> >
> > Putting a user hat on, here are the things that I would like to do:
> > 1) Unit test a component without needing any SCA runtime
> > infrastructure. I don't need Tuscany classes on the classpath to
> > compile my component and I don't want to pollute my test environment
> > with them. All I should need is my code and my test framework (for
> > example, TestNG).
> >
> > 2) Function test a component in the SCA runtime. I have installed and
> > configured Tuscany somewhere, adding in the extensions that I need. I
> > want to test code as if it was running in that environment. Ideally I
> > would like the runtime to boot quickly inside my test client but I
> > would also like to be able to deploy the component to an already
> > running environment.
> >
> > --
> > Jeremy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
Re: How to use extensions with the standalone launcher?
Posted by ant elder <an...@gmail.com>.
How about until we have a way to do extensions properly to fix the problem
Matthew is seeing the testcase could determine which is the application
default.scdl by seeing if the resource URL starts with the current working
directory which it can get from System.getProperty("user.dir")?
...ant
On 8/1/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Aug 1, 2006, at 11:28 AM, Matthew Sykes wrote:
>
> > FWIW, I think I've been running into a problem at build time
> > because of this exact issue. There's a bit of code in the
> > javascript sample HelloWorldTestCase.java test that gathers up all
> > of the META-INF/sca/default.scdl resources it can find. The test
> > then throws away the first resource in the enumeration assuming
> > it's the application's default.scdl and not the extension's
> > default.scdl.
>
> I think this is problematic - putting all the runtime code on the
> application classpath is asking for trouble.
>
> > ant elder wrote:
> >> I guess it somehow needs to find the URL to the default.scdl for the
> >> JavaScript extension, but thats just in a jar on the classpath and
> >> there's
> >> lots of default.scdl resources on the class path so how does it
> >> know which
> >> is the JavaScript one?
> >> And the once it has that URL it isn't real obvious (to me) how you
> >> could use
> >> that from the testcase to get the extension registered with the
> >> runtime.
> >> ...ant
> >
> > While the build generally succeeds, every once in a while the test
> > fails with an UnrecognizedElementException on implementation.js. I
> > added a System.out.println to the test to show which of the
> > resources was thrown away in the following code snippet and found
> > that the extension scdl can be discarded instead of the application
> > scdl. (I'm assuming this is because enumeration that comes back
> > from getResources doesn't have a specfied order.)
> >
> > At this point I guess I have to wonder if the name used for the
> > extensions' scdl should be something different from the default
> > application scdl name? It seems like it might be nice to do
> > something like gather up like all of the visible META-INF/sca/
> > extension.scdl resources and add them to the runtime as
> > extensions. I don't believe this would be at odds with the current
> > extensions mechanism in the DirectoryScanExtender if it went after
> > extension.scdl instead of default.scdl.
>
> I don't think we want different types of composite for extensions and
> other things.
>
> We're trying to add extensions into test cases without defining an
> extension mechanism so it's not surprising things are not working
> properly. Perhaps we should back up a little and think about what we
> are trying to achieve.
>
> Putting a user hat on, here are the things that I would like to do:
> 1) Unit test a component without needing any SCA runtime
> infrastructure. I don't need Tuscany classes on the classpath to
> compile my component and I don't want to pollute my test environment
> with them. All I should need is my code and my test framework (for
> example, TestNG).
>
> 2) Function test a component in the SCA runtime. I have installed and
> configured Tuscany somewhere, adding in the extensions that I need. I
> want to test code as if it was running in that environment. Ideally I
> would like the runtime to boot quickly inside my test client but I
> would also like to be able to deploy the component to an already
> running environment.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: How to use extensions with the standalone launcher?
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 1, 2006, at 11:28 AM, Matthew Sykes wrote:
> FWIW, I think I've been running into a problem at build time
> because of this exact issue. There's a bit of code in the
> javascript sample HelloWorldTestCase.java test that gathers up all
> of the META-INF/sca/default.scdl resources it can find. The test
> then throws away the first resource in the enumeration assuming
> it's the application's default.scdl and not the extension's
> default.scdl.
I think this is problematic - putting all the runtime code on the
application classpath is asking for trouble.
> ant elder wrote:
>> I guess it somehow needs to find the URL to the default.scdl for the
>> JavaScript extension, but thats just in a jar on the classpath and
>> there's
>> lots of default.scdl resources on the class path so how does it
>> know which
>> is the JavaScript one?
>> And the once it has that URL it isn't real obvious (to me) how you
>> could use
>> that from the testcase to get the extension registered with the
>> runtime.
>> ...ant
>
> While the build generally succeeds, every once in a while the test
> fails with an UnrecognizedElementException on implementation.js. I
> added a System.out.println to the test to show which of the
> resources was thrown away in the following code snippet and found
> that the extension scdl can be discarded instead of the application
> scdl. (I'm assuming this is because enumeration that comes back
> from getResources doesn't have a specfied order.)
>
> At this point I guess I have to wonder if the name used for the
> extensions' scdl should be something different from the default
> application scdl name? It seems like it might be nice to do
> something like gather up like all of the visible META-INF/sca/
> extension.scdl resources and add them to the runtime as
> extensions. I don't believe this would be at odds with the current
> extensions mechanism in the DirectoryScanExtender if it went after
> extension.scdl instead of default.scdl.
I don't think we want different types of composite for extensions and
other things.
We're trying to add extensions into test cases without defining an
extension mechanism so it's not surprising things are not working
properly. Perhaps we should back up a little and think about what we
are trying to achieve.
Putting a user hat on, here are the things that I would like to do:
1) Unit test a component without needing any SCA runtime
infrastructure. I don't need Tuscany classes on the classpath to
compile my component and I don't want to pollute my test environment
with them. All I should need is my code and my test framework (for
example, TestNG).
2) Function test a component in the SCA runtime. I have installed and
configured Tuscany somewhere, adding in the extensions that I need. I
want to test code as if it was running in that environment. Ideally I
would like the runtime to boot quickly inside my test client but I
would also like to be able to deploy the component to an already
running environment.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to use extensions with the standalone launcher?
Posted by Matthew Sykes <sy...@gmail.com>.
FWIW, I think I've been running into a problem at build time because of
this exact issue. There's a bit of code in the javascript sample
HelloWorldTestCase.java test that gathers up all of the
META-INF/sca/default.scdl resources it can find. The test then throws
away the first resource in the enumeration assuming it's the
application's default.scdl and not the extension's default.scdl.
ant elder wrote:
> I guess it somehow needs to find the URL to the default.scdl for the
> JavaScript extension, but thats just in a jar on the classpath and there's
> lots of default.scdl resources on the class path so how does it know which
> is the JavaScript one?
>
> And the once it has that URL it isn't real obvious (to me) how you could
> use
> that from the testcase to get the extension registered with the runtime.
>
> ...ant
While the build generally succeeds, every once in a while the test fails
with an UnrecognizedElementException on implementation.js. I added a
System.out.println to the test to show which of the resources was thrown
away in the following code snippet and found that the extension scdl can
be discarded instead of the application scdl. (I'm assuming this is
because enumeration that comes back from getResources doesn't have a
specfied order.)
At this point I guess I have to wonder if the name used for the
extensions' scdl should be something different from the default
application scdl name? It seems like it might be nice to do something
like gather up like all of the visible META-INF/sca/extension.scdl
resources and add them to the runtime as extensions. I don't believe
this would be at odds with the current extensions mechanism in the
DirectoryScanExtender if it went after extension.scdl instead of
default.scdl.
Just a thought.
--
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to use extensions with the standalone launcher?
Posted by ant elder <an...@gmail.com>.
I've still not figured out how to get extensions used in testcases so any
pointers to existing methods or code snippets of what you mean would be
really helpful.
As an example how would the testcase for the JavaScript helloworld work:
http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/helloworldJavaScript/src/test/java/helloworld/HelloWorldTestCase.java
I guess it somehow needs to find the URL to the default.scdl for the
JavaScript extension, but thats just in a jar on the classpath and there's
lots of default.scdl resources on the class path so how does it know which
is the JavaScript one?
And the once it has that URL it isn't real obvious (to me) how you could use
that from the testcase to get the extension registered with the runtime.
...ant
On 7/28/06, ant elder <an...@gmail.com> wrote:
>
> Registering the extension in the test setup seems fine, I'm out for the
> night now and you'll likely not be around in the morning my time, so could
> you post a pointer to a method/class that does the setup you're talking
> about?
>
> Note also that along with the maven build the test environment can also
> run in an IDE, eg running testcases within eclipse.
>
> Thanks,
>
>
> ...ant
>
> On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
> >
> > The "extension" directory is only scanned by the standalone launcher
> > and not by the test environment. The test environment runs in maven
> > and gets all its artifacts from the maven classloader rather than by
> > scanning directories. It sounds like we should define an extension
> > mechanism for the test harness, perhaps tied into maven extensions.
> >
> > In the mean time a workaround may be to register the composite for
> > the JavaScript container with the runtime in the setup phase of the
> > test. There are code examples for that in the Launcher, or ping me if
> > I can help.
> >
> > --
> > Jeremy
> >
> > On Jul 28, 2006, at 9:44 AM, ant elder wrote:
> >
> > > I'm still struggling getting this to go. I've added a JavaScript
> > > HelloWorld
> > > sample to help (in samples/sca/helloworldJavaScript). The testcase
> > > for that
> > > sample fails as it doesn't understand the javascript SCDL, as I guess
> > > SCATestCase doesn't know about the JavaScript container. Am I
> > > supposed to
> > > register the container somehow?
> > >
> > > ...ant
> > >
> > > On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
> > >>
> > >> The launcher scans a directory called "extensions" under the root and
> >
> > >> deploys everything it finds there as a child to the system
> > >> composite -
> > >> just dropping a jar containing a "default.scdl" in there should
> > >> add it
> > >> in.
> > >>
> > >> We should write this up better but here's the original post to the
> > >> list:
> > >>
> > >> http://article.gmane.org/
> > >> gmane.comp.apache.webservices.tuscany.devel /4980/match=extension
> > >>
> > >> --
> > >> Jeremy
> > >>
> > >> On 7/28/06, ant elder <an...@gmail.com> wrote:
> > >> > I'm trying to get some standalone JavaScript samples working but
> > >> I'm not
> > >> > sure how the javascript container jar is supposed to be used
> > >> with the
> > >> > launcher. Is there a special place I need to put the jar, or a
> > >> parameter to
> > >> > use to tell the launcher where the jar is?
> > >> >
> > >> > ...ant
> > >> >
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> >
> > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: How to use extensions with the standalone launcher?
Posted by ant elder <an...@gmail.com>.
Registering the extension in the test setup seems fine, I'm out for the
night now and you'll likely not be around in the morning my time, so could
you post a pointer to a method/class that does the setup you're talking
about?
Note also that along with the maven build the test environment can also run
in an IDE, eg running testcases within eclipse.
Thanks,
...ant
On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> The "extension" directory is only scanned by the standalone launcher
> and not by the test environment. The test environment runs in maven
> and gets all its artifacts from the maven classloader rather than by
> scanning directories. It sounds like we should define an extension
> mechanism for the test harness, perhaps tied into maven extensions.
>
> In the mean time a workaround may be to register the composite for
> the JavaScript container with the runtime in the setup phase of the
> test. There are code examples for that in the Launcher, or ping me if
> I can help.
>
> --
> Jeremy
>
> On Jul 28, 2006, at 9:44 AM, ant elder wrote:
>
> > I'm still struggling getting this to go. I've added a JavaScript
> > HelloWorld
> > sample to help (in samples/sca/helloworldJavaScript). The testcase
> > for that
> > sample fails as it doesn't understand the javascript SCDL, as I guess
> > SCATestCase doesn't know about the JavaScript container. Am I
> > supposed to
> > register the container somehow?
> >
> > ...ant
> >
> > On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
> >>
> >> The launcher scans a directory called "extensions" under the root and
> >> deploys everything it finds there as a child to the system
> >> composite -
> >> just dropping a jar containing a "default.scdl" in there should
> >> add it
> >> in.
> >>
> >> We should write this up better but here's the original post to the
> >> list:
> >>
> >> http://article.gmane.org/
> >> gmane.comp.apache.webservices.tuscany.devel/4980/match=extension
> >>
> >> --
> >> Jeremy
> >>
> >> On 7/28/06, ant elder <an...@gmail.com> wrote:
> >> > I'm trying to get some standalone JavaScript samples working but
> >> I'm not
> >> > sure how the javascript container jar is supposed to be used
> >> with the
> >> > launcher. Is there a special place I need to put the jar, or a
> >> parameter to
> >> > use to tell the launcher where the jar is?
> >> >
> >> > ...ant
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: How to use extensions with the standalone launcher?
Posted by Jeremy Boynes <jb...@apache.org>.
The "extension" directory is only scanned by the standalone launcher
and not by the test environment. The test environment runs in maven
and gets all its artifacts from the maven classloader rather than by
scanning directories. It sounds like we should define an extension
mechanism for the test harness, perhaps tied into maven extensions.
In the mean time a workaround may be to register the composite for
the JavaScript container with the runtime in the setup phase of the
test. There are code examples for that in the Launcher, or ping me if
I can help.
--
Jeremy
On Jul 28, 2006, at 9:44 AM, ant elder wrote:
> I'm still struggling getting this to go. I've added a JavaScript
> HelloWorld
> sample to help (in samples/sca/helloworldJavaScript). The testcase
> for that
> sample fails as it doesn't understand the javascript SCDL, as I guess
> SCATestCase doesn't know about the JavaScript container. Am I
> supposed to
> register the container somehow?
>
> ...ant
>
> On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> The launcher scans a directory called "extensions" under the root and
>> deploys everything it finds there as a child to the system
>> composite -
>> just dropping a jar containing a "default.scdl" in there should
>> add it
>> in.
>>
>> We should write this up better but here's the original post to the
>> list:
>>
>> http://article.gmane.org/
>> gmane.comp.apache.webservices.tuscany.devel/4980/match=extension
>>
>> --
>> Jeremy
>>
>> On 7/28/06, ant elder <an...@gmail.com> wrote:
>> > I'm trying to get some standalone JavaScript samples working but
>> I'm not
>> > sure how the javascript container jar is supposed to be used
>> with the
>> > launcher. Is there a special place I need to put the jar, or a
>> parameter to
>> > use to tell the launcher where the jar is?
>> >
>> > ...ant
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to use extensions with the standalone launcher?
Posted by ant elder <an...@gmail.com>.
I'm still struggling getting this to go. I've added a JavaScript HelloWorld
sample to help (in samples/sca/helloworldJavaScript). The testcase for that
sample fails as it doesn't understand the javascript SCDL, as I guess
SCATestCase doesn't know about the JavaScript container. Am I supposed to
register the container somehow?
...ant
On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> The launcher scans a directory called "extensions" under the root and
> deploys everything it finds there as a child to the system composite -
> just dropping a jar containing a "default.scdl" in there should add it
> in.
>
> We should write this up better but here's the original post to the list:
>
> http://article.gmane.org/gmane.comp.apache.webservices.tuscany.devel/4980/match=extension
>
> --
> Jeremy
>
> On 7/28/06, ant elder <an...@gmail.com> wrote:
> > I'm trying to get some standalone JavaScript samples working but I'm not
> > sure how the javascript container jar is supposed to be used with the
> > launcher. Is there a special place I need to put the jar, or a
> parameter to
> > use to tell the launcher where the jar is?
> >
> > ...ant
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: How to use extensions with the standalone launcher?
Posted by ant elder <an...@gmail.com>.
Ok! Thanks. Its defined in
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/commands/launcher/src/main/resources/META-INF/tuscany/system.scdl
I should have scanned with .* not .java. Anyway the key thing is the
directory is named "extension" not "extensions".
...ant
On 7/30/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Jul 30, 2006, at 3:06 AM, ant elder wrote:
>
> > On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
> >>
> >> The launcher scans a directory called "extensions" under the root and
> >> deploys everything it finds there as a child to the system
> >> composite -
> >> just dropping a jar containing a "default.scdl" in there should
> >> add it
> >> in.
> >
> >
> > I can't get this to work after trying various combinations of
> > locations and
> > names, and also can't find any launcher code the mentions
> > "extensions".
>
> There isn't any code for this in the launcher. The configuration it
> loads contains a "DirectoryScanExtender" component which is what
> scans the directory.
>
>
> > I
> > have got the JavaScript container working with the launcher but
> > only by
> > hacking the launcher.jar to add a javaScriptImplementation.scdl and
> > adding
> > that as an include in the system.scdl.
> >
> > Is this extension mechanism actually implemented yet, or could you
> > give me
> > any more pointers or how to get it to work?
>
> I'll take a look at what you have (I'm assuming it's all in svn, if
> not can you send the delta to the list) and post some suggestions.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: How to use extensions with the standalone launcher?
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 30, 2006, at 3:06 AM, ant elder wrote:
> On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> The launcher scans a directory called "extensions" under the root and
>> deploys everything it finds there as a child to the system
>> composite -
>> just dropping a jar containing a "default.scdl" in there should
>> add it
>> in.
>
>
> I can't get this to work after trying various combinations of
> locations and
> names, and also can't find any launcher code the mentions
> "extensions".
There isn't any code for this in the launcher. The configuration it
loads contains a "DirectoryScanExtender" component which is what
scans the directory.
> I
> have got the JavaScript container working with the launcher but
> only by
> hacking the launcher.jar to add a javaScriptImplementation.scdl and
> adding
> that as an include in the system.scdl.
>
> Is this extension mechanism actually implemented yet, or could you
> give me
> any more pointers or how to get it to work?
I'll take a look at what you have (I'm assuming it's all in svn, if
not can you send the delta to the list) and post some suggestions.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: How to use extensions with the standalone launcher?
Posted by ant elder <an...@gmail.com>.
On 7/28/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> The launcher scans a directory called "extensions" under the root and
> deploys everything it finds there as a child to the system composite -
> just dropping a jar containing a "default.scdl" in there should add it
> in.
I can't get this to work after trying various combinations of locations and
names, and also can't find any launcher code the mentions "extensions". I
have got the JavaScript container working with the launcher but only by
hacking the launcher.jar to add a javaScriptImplementation.scdl and adding
that as an include in the system.scdl.
Is this extension mechanism actually implemented yet, or could you give me
any more pointers or how to get it to work?
Thanks,
...ant
Re: How to use extensions with the standalone launcher?
Posted by Jeremy Boynes <jb...@apache.org>.
The launcher scans a directory called "extensions" under the root and
deploys everything it finds there as a child to the system composite -
just dropping a jar containing a "default.scdl" in there should add it
in.
We should write this up better but here's the original post to the list:
http://article.gmane.org/gmane.comp.apache.webservices.tuscany.devel/4980/match=extension
--
Jeremy
On 7/28/06, ant elder <an...@gmail.com> wrote:
> I'm trying to get some standalone JavaScript samples working but I'm not
> sure how the javascript container jar is supposed to be used with the
> launcher. Is there a special place I need to put the jar, or a parameter to
> use to tell the launcher where the jar is?
>
> ...ant
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org