Hi,
Heres just a random collection of thoughts on about the feasability of
allowing access to Kernel services such as
* Deployer interface
* Kernel interface (and thus Application interfaces)
* Embeddor interface
* SystemManager interface
* MBeanServer interface
* LogManager interface
* ConfigurationManager interface
etc.
from within a Sar.
Making these interfaces available from a .sar makes it much easier to
implement certain features in application land rather than kernel land. For
instance you could implement a JMX agent, DeployMonitor or other similar apps
in application land rather than kernel land. The advantage of this being that
you have access to all Cornerstone services + other Blocks which makes it
easier to develope.
So lets say you wanted to create a Agent that monitors MBeanServer and
exports it via telnet, as a webapp, RMI or via some other system. Currently
you would have to write it in Kernel space which is a bit painful and doesn't
allow reuse but if it was in application space you could easily use
Jetty/Tomcat or whatever to run webapp, jtelnetd to run tlenet daemon or
whatever. And things become much easier (just drop .sar file into ./apps to
enable agent).
There are negatives. Allowing access to such services creates a higher
coupling between the .sar and the kernel. Thus it makes it harder to evolve
the kernel and any "privlidegd" .sars (ie those who have access to kernel
services).
So...
Pros:
* Easy to enhance functionality of kernel by adding a .sar rather than
modifying kernel.
* Application space is easier to work in.
* Application space makes components more reusable
* Easily have multiple implementations of same "functionality". ie one SNMP
Agent and one Web based management agent
Cons:
* Tighter binding between .sar and kernel
* Privlidged .sars may become bound to specific kernel implementations
* Requires the interfaces to be placed in shared jar
* We may have to do extensive guarding of threads in future (though not for a
while) so that each Application and the Kernel all have different
ThreadGroups.
So if we do decide to add this there are some open questions:
- Where to we declare a dependency on Kernel services? Do we declare it at
Block level or at .sar level ? ie in blockinfo files or assembly files?
- And thus where do we make the services available? in ComponentManager or
via BlockContext?
- What should format of dependency look like? ie
<kernel-services>
<service name="org.apache.avalon.phoenix.interfaces.Deployer"
version="1.0"/>
</kernel-services>
or wither other dependencies in blockinfo
<dependencies>
<kernel-service name="org.apache.avalon.phoenix.interfaces.Deployer"
version="1.0"/>
</dependencies>
or some other form?
- Which Kernel components should we export? Deployer seems like a candidate
as does MBeanServer, perhaps Embeddor aswell (so jesktop can shutdown phoenix
gracefully)
- other factors?
Thoughts on any of this???
--
Cheers,
Pete
*----------------------------------------------*
| The best defense against logic is ignorance. |
*----------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
