Rob Evans wrote:
On Wed, 06 Oct 2004 08:59:26 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
Rob Evans wrote:
Could be. I for o
It sounds like we are on the same page regarding the nature of the
solution i.e. we're after something that looks like components. I'm
sure Craig and Halloway will have something to say about this if you
can get their attention.
I hope so. I have to admit that I cannot approach the horsepower they
would bring to a discussion like this. I am convinced, however, that
the smaller the core and the more extensible the whole design, the
better things are. Getting the kernel right, however, and getting a
design for growth right, is the key. I am convinced myself that Struts
has the essential i
I'm not sure that in the end a full blown component model for webapp
is necessary. Do we really need to start/stop/reload webapp
contributions? Is it even possible to reload a contribution without
bouncing the webapp. Maybe, I don't know.
Yes, it is. There are requirements. (1) clients must not reference the
type that will be dynamically reloaded, if they do, either they will
implicity load the classes with their class loader or fail to load the
classes at all, and these options require shutting down the client
(which is what we want to avoid with this design decision); (2) clients
can never use a reference to an implementation type, but must always
reference a base class or an interface type (there is no way to avoid
shutting down the client if you want to change the interface or the base
class that is referenced, but this would require the client to be
rewritten anyway, so there is no real penalty); (3) the implementation
must be able to find the same version of the interface that the client
is using, or, in other words, the implementation's classloader must
delegate to the client's classloader (easily done by having clients
loaded with the system classloader). New implementations can use old
implemenations as a template, thereby maintaining state. This has two
requirements. (A) the client must make the state of the original object
available to factory class that serves the implementations so that the
new version can be correctly instantiated; (B) the client must drop all
references to the old version to drop the old version and to use the new
one (easily done by using the same variable), which Halloway shows as a
single line of code in his example: "pt = PointFactory.createPoint(pt);".
Most of the light weight
containers don't bother with hotdeployment and instead focus on the
IOC/Dependancy Injection. Perhaps, this would be a good place to
start?
The focus on IoC or Dependency Injection is perfect, I think
(http://www.martinfowler.com/articles/injection.html). My driving
philosophy is this: don't create a single dependency that is not
necessary. So, for example, if possible, the kernel should provide for
development in different flavors of Dependency Injection. I would tend
to favor the interface flavor. But, there are reasons to do things
differently.
I'm tempted to send an email to one of the eclipse lists and see what
they think.
Sounds good.
Michael McGrady
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
