Folks,
I've been working quite a bit in the Commons project on the ARMI tool.
First off, it has to be renamed - ARMI is used by an academic group as
"Asynchonous RMI". Secondly I'm not getting huge approval (in one case
outright hostility) there - I do not know if there will be a consensus
of +1s by committers when it comes to move ARMI from 'sandbox' to 'main'.
The reason it is relevant to Avalon in that it has the capability to
connect two applications inside the same VM but in mutually invisible
ClassLoaders. Consider Tomcat (when we ultimately get it working on
Avalon-Phoenix). Consider JAMES wanting to push a whole WAR file to
Tomcat at startup. That WAR file application could, in accordance with
the Servlet Spec, only use an RMI type lookup for JAMES services, or
could (outside the Servlet Spec) drill through to JAMES via some
internal Avalon broker of services. For the context of this discussion
we're interested in the interoperation with Tomcat's internals rather
than the functionings of particular web-app. The Tomcat team
thoughtfully provided some interface abstractions that allow another
application to embed Tomcat and then invoke virtual-site and web-app
manipulation methods.
Considering the two apps listed above, Phoenix will mount the two apps
in seperate classloaders:
Tomcat JAMES
| |
--------------------------- Phoenix Impl
| |
Phoenix interface -------------------
|
System/Boot/Primordial
What ARMI can provide in this instance is a pipe between Tomcat and
JAMES for the manipulation interfaces of Tomcat. Let us say that Tomcat
came in two jars - tomcat-interface.jar and tomcat-implementation.jar
(actually it is way more than two). Lets say that the SAR file for
Tomcat and the SAR file for JAMES both contain the same
tomcat-interfaces.jar. What ARMI can provide is a publication of the
Tomcat interfaces from within the Phoenix mounted Tomcat classloader to
otherwise invisible JAMES classloader. The mecahnics of this are a
Pipe, an ObjectStream and serialization. Because of the serialization
step, the two seperate classloaders do not throw ClassCast exceptions *2.
Now ARMI is pitched towards publication of Facades (we are all aware of
the Facade pattern?). Essentially this is because it has two types of
class that it is handling. Those that are serialzable and those that
are facades. Facades can have methods that can return other facades.
ARMI handles this quite well. Facades can habe methods that list
amongst their parameters other Facades. ARMI can't yet but will handle
this as well. All int essentially needs is a decent interface/impl
seperation. In fact the interface it publishes need not actually be a
good example of the facade pattern - ARMI does not care.
For free, ARMI can also provide truly remote publication (via sockets or
RMI). For free also, given that the Pipe impl serializes, ARMI can
support multiple versons of the same APIs in the same Phoenix VM. It
may also be able to do some within-limits adaption between subtally
different versions of the same API.
What we don't know at this stage (making the massive assumption that
Peter, Berin et al are as keen as I am) is how much we use ARMI. We
could easily create a Cornerstone block that is geared towards the two
remote publications impls (sockets and RMI). We could also, as outlined
above, allow Phoenix to directly (under configuration) use ARMI to allow
one block to <depend> on a service of others irrespective of the
location of that service. It could nearly seamlessly mesh into the
current org.apache.avalon.framework.component.ComponentManager API.
See the proposal at
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/armi/
Thoughts?
Regards,
- Paul H
*1 We are referring to Tomcat. Really Tomcat 4.x series is called
'Catalina'.
*2 When the JVM condsiders the eligibility for an Object to be cast
into, say ABCClass, it is actually secretly considering the ClassLoader
as part of the Class name. Such that if ABCClass.class existed in two
seperate classloaders in the tree and the were exactly the same version
and impl, an instance from one would not be satisfactorily testable via
.equals() or castable in the context of the other.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
