-----Original Message----->
What kind of extensions are we talking about? From your doc, I can see
* Management Extensions * Directory Extensions * Container Components
Management extensions would include certain things like JMX support and Instrumentation support.
Directory extensions would include JNDI integration, context value customization, etc.
Container Components include privileged code that runs in the container space. Perhaps a shutdown component, or something else along those lines.
Sounds good to me.
Is there anything else?
Probably.
Specifically I've been thinking about SOAP and JMS. For example, in JMS you have a MessageListener interface which provides an onMessage(Message msg) method. If an Avalon service were able to tell a JMS-enabled container what JMS destination it wants to listen to, the container could take care of subscribing it to the destination. In the end you get an Avalon version of Message Driven Beans.
Hmm. SOAP, AltRMI, RMI, etc. are all remoting protocols. We should make this as plugable as possible and as invisible to the user as we can.
JMS is a messaging service, which can be analogous to an event based system. Whether it is using JMS or some other application, we need to provide some mechanism for it.
This can pretty much be done using Lifecycle extensions now (I'm almost done with one version) but would be significantly easier if the extensions could get a hold of assembly attributes for the component which could convey the JMS destination information.
:) Understood. Extensions should probably be formally made into priviledged components (i.e. container-space components) which should have the additional access to component meta info and assembly info.
Same holds for (Alt)RMI exporting of objects. I suppose these all fall into the "Directory Extensions" you mention.
(Alt)RMI is a remoting tool. Directory Extensions are more for JNDI integration.
More random thoughts:
One way I've been looking at it is to try to figure out the basic roles or lifecycles of a container (this is not a perfect list):
- Establish Runtime Environment (Context) - Assemble Components - Provide Resources/Bundles - Handle Lifecycle - Handle Component Access (Lookups) - Handle Component decommissioning
and so on.
Yep.
Next is to determine which of these are valid for extension. Perhaps all are. Perhaps only certain ones make sense. I'm still in the "thinking about it" stage on this one. However, off the top of my head, here are some other container extensions which might be interesting:
Let's focus on one use case at a time. Let's start by trying to solve one problem, and then we can move to the next. By the time we are done, we will have the best set of interfaces/etc.
- Clustering and Failover
Ambitious aren't we? This means we need a better security model... We don't want someone to force us to fail over to an unauthorized backup do we?
- Transparent Remote Service Lookup (looking up services across VMs)
Yep. That's the (Alt)RMI connection there.
- Resource loading/downloading (Downloading from Maven or JNLP repository)
Again, security model improvements are needed. Signing of JARs, etc.
- Hot deploy of services
We might want to start here... Again security model applies.
- Support for JINI or Javaspaces
Licensing! It's not easy working with patent enabled technologies.
It's also a question of which of these could be implemented as normal
services under Avalon 4 and which would require new capabilities. Not
saying I have all the answers, but I certainly have a bunch of questions.
:)
If you ask the right questions, you just might get an answer you like. :)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
