Jeremy Boynes wrote:
I'd like to find out more about what you've done, if we can take this
discussion out of the group, and then perhaps present a way of how we
might use these kind of ideas to provide a micro-kernel architecture
for the system.
Please don't take it out of this forum - this is a useful discussion for
everyone.
We are currently using a JMX kernel for historical reasons, and because it
lets us get something running really quickly. At this time I think getting
something running is a better plan than getting the best thing designed as
it lets other subprojects (like the verifier) get going. This is a project
management thing, not a technical one.
I agree that this approach is probably the best in the short term. I do
have
one major concern that I would like to be addressed in the current release
though:
Please make all server components use the following semantics:
* Separate interface from implementation
* Allow all runtime artifacts to be given to the container during init time
(Inversion of Control principle).
* Don't finalize the contracts too early.
Using these three principles we can avoid static accessors to runtime
artifacts like JNDI (passing in a Context object is better than using the
InitialContext class for the core components).
This will give us the widest flexibility when it comes to choosing our
server component container. The solution will allow us to swap out the
container for something else without forcing us into one approach too
early.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
