Farr, Aaron wrote:
-----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 3:29 PM To: Avalon Developers List Subject: Re: [merlin] JNDI, Engines, and other fun
It sounds feasible. I haven't made any progress on the JNDI side of
things - been a touch busy on "other stuff" (patches, docs, the MGR/JMX
stuff, internal affairs, private life, etc.). If you like I can dump the
stuff I've been playing with into sandbox (its not much more than a
primitive provider implementation - mainly for me to get my head around
JNDI).
Sounds great. I'd love to see it in the sandbox.
Done. merlin/merlin-extensions/merlin-jndi-new
The JNDI exporting of services would be fantastic.
Hmm. Thought I had a brilliant idea there and, nope, it won't work (well,
not as smoothly as I thought).
The idea is behind lifecycle extensions. They're great and I'm putting together a couple, but I just wish they had access to the component meta-data, or even configuration. In merlin, we might be able to get a hold of the appliance information, which would work. But no other containers support this (yet). I just think it would be really nice to have a standard way to extend a container that provided meta-data. So this JNDI export feature could be a standard extension, easily plugged into other containers.
First move is to get broader adaption of the meta-info model (org.apache.avalon.meta.info). It is container neutural and addresses the bulk of requirements across all containers. Getting to something like the Appliance interface is interesting because it skips the container specific meta-data, but I think we need to demonstrate this as a viable containment extension solution first.
I'm looking for container extensions, of which lifecycle extensions are a subset. Some extensions (like JNDI binding) are not a lifecycle but a deployment or assembly extension so they need to know the component meta-data. JMX bindings are similar. If there were a standard way to extend containers, then it wouldn't need to be done for each one. Write JNDI exporting once and wham! You've got it for phoenix, fortress, merlin, etc.
Does this make sense? Is this already possible and I'm just missing something?
I've been playing around with the incorporation of an internal engine inside the Merlin Kernel with objective of using this to establish optional container services. This is similar to the Phoenix approach of configured components but gopes the step further of enabling full components inside the container. Natuarally there are a couple of bootstraping issues, but I'm confident that this is the way to go forward. Using this approach things like JNDI or JMX management become plugin components into the container.
E.g. what I have in mind ....
<kernel>
<implementation>
<classloader>
<classpath>
<!--
additional jar to loaded into the container
private classloader go here
-->
</classpath>
</classloader> <component name="jmx"
class="org.apache.avalon.merlin.jmx.RMIServerAdapter">
<configuration>
<!-- stuff -->
</configuration>
</componet> <component name="jndi"
class="org.apache.avalon.merlin.jmx.JNDIAdapter">
<configuration>
<!-- stuff -->
</configuration>
</componet></implementation>
</kernel>
I have locally an implementation of something that will do the
downloading from file or http urls (adapted from some content in
maven-new). I want to tie this into the FileRepository impementation so
that we auto download content - but with one caveat over and above the
Maven approach - I want to be able to declare the security policy to
apply on downloaded content (certification validation against a trust
store, etc) and as such, I want to keep validated artifact separate from
the Maven repository.
Hmm. I guess I'll wait to see what you have already put together. This
sounds good.
Will try and roll this together tommorow.
Cheers, Steve.
Oh, and I have PheonixJMS (OpenJMS) up and running in Merlin properly.I would love to take a look at this!
I'll put it up on my server tonight.
- jaaron
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
