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