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