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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
