You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/01/06 23:55:30 UTC
Re: Armi - Alternate to RMI (Commons-scratchpad)
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Peter Royal <pr...@managingpartners.com>.
On Monday 07 January 2002 11:42 am, Paul Hammant wrote:
> <fx>ducks</fx> I have just asked them to seperate into interface and
> impl again. By accident some of the Catalina "interface" code imports
> and uses impl code. For good reasons in the 4.0.x series they do not
> want to fix that. They *might* be willing to seperate all the
> interfaces and accidentally depended on packages/classes to a
> catalina-interface.jar and leave the rest in catalina-impl.jar. Fingers
> crossed, when it happens it might rejuvenate 'bay'.... wanna take it over?
I can't just yet, as working on all this is via my day-job atm and there are
other things for me to do that have a higher priority. However, speeding up
our system is still on the list and bringing it all into the same JVM will be
a tremendous boost. At that time, (expected to be within the next month or
two), and if the Catalina folk have heeded your suggestion and thus breathe
new life into Bay, I'd be happy to take it over. (Thus we'd be using it in
production -> quasi-corporate sponsorship to keep it all working :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>and I would love to get that working with Catalina.
>
<fx>ducks</fx> I have just asked them to seperate into interface and
impl again. By accident some of the Catalina "interface" code imports
and uses impl code. For good reasons in the 4.0.x series they do not
want to fix that. They *might* be willing to seperate all the
interfaces and accidentally depended on packages/classes to a
catalina-interface.jar and leave the rest in catalina-impl.jar. Fingers
crossed, when it happens it might rejuvenate 'bay'.... wanna take it over?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Peter Royal <pr...@managingpartners.com>.
On Sunday 06 January 2002 05:55 pm, Paul Hammant wrote:
> 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.
I just wanted to chime in that your ARMI work looks great! I haven't had a
chance to mess with it yet but I will be playing with in on my next iteration
of performance tuning over here. The intra-JVM pieces sound very interesting
and I would love to get that working with Catalina.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Paul Hammant <Pa...@yahoo.com>.
> 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 have methods that
> list amongst their parameters other Facades. ARMI can't yet but will
> handle this as well. All it 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.
Issue with ARMI not accepting other facades as parameters now fixed.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Peter Donald <pe...@apache.org>.
On Mon, 7 Jan 2002 21:41, Eung-ju Park wrote:
> How about below configuration? But Paul have better idea than me. :-)
>
> -- assembly.xml
>
> <block-listener
> class="org.apache.avalon.cornerstone.listeners.armi.ArmiPublisher"
> name="armi">
> ...
> ...
> </block-listner>
>
> <block class="org.apache.avalon.foo.blocks.Bar" name="barbar">
> ...
> </block>
>
> -- config.xml
> <armi>
> <publish name="Bar">
> <block>barbar</block>
> <interface>org.apache.avalon.foo.services.Bar1</interface>
> <interface>org.apache.avalon.foo.services.Bar2</interface>
> </publish>
> <publish name="X1">
> ...
> </publish>
> </armi>
Looks good to me ;)
--
Cheers,
Pete
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter, Eung-ju,
>>one of the joys of commons. People who don't work on the code get voting
>>rights. Fun - aint it?
>>
Oh blimey it is worse that I thought. I think I should brace for a "no"
vote.
>>>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.
>>>
>>I don't think it is time to put it inside the Phoenix "kernel" just yet
>>
>and
>
>>have not yet reached a stable point in ClassLoader etc arrangement.
>>
I would be inclined to agree.
>>If you
>>want to have an exporter Block then great ;)
>>
Yes I think that is first - a Cornerstone exporter/publisher
>>It would also be possible to
>>
>add
>
>>a BlockListener that automagiocally published different Blocks into the
>>
>ARMI
>
>>exporter.
>>
This sounds good. I nead to learn a little about when/why one would use
a BlockListener I guess.
>
>How about below configuration? But Paul have better idea than me. :-)
>
>-- assembly.xml
>
><block-listener
>class="org.apache.avalon.cornerstone.listeners.armi.ArmiPublisher"
>name="armi">
> ...
> ...
></block-listner>
>
><block class="org.apache.avalon.foo.blocks.Bar" name="barbar">
> ...
></block>
>
>-- config.xml
><armi>
> <publish name="Bar">
> <block>barbar</block>
> <interface>org.apache.avalon.foo.services.Bar1</interface>
> <interface>org.apache.avalon.foo.services.Bar2</interface>
> </publish>
> <publish name="X1">
> ...
> </publish>
></armi>
>
One problem is that the ARMI equivalent of RMI syubs need to exist. I
planned a BCEL dynamic generator, but am completely stuck (as ever) with
how to do it in BCEL.
I like the look of this though.
>>I don't have time to play atm but it sounds neat.
>>
Thanks dudes.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Eung-ju Park <co...@apache.org>.
----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Monday, January 07, 2002 5:07 PM
Subject: Re: Armi - Alternate to RMI (Commons-scratchpad)
> On Mon, 7 Jan 2002 09:55, Paul Hammant wrote:
> > 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)
>
> im not surprised ;)
>
> > 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'.
>
> one of the joys of commons. People who don't work on the code get voting
> rights. Fun - aint it?
>
> > 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.
>
> I don't think it is time to put it inside the Phoenix "kernel" just yet
and
> have not yet reached a stable point in ClassLoader etc arrangement. If you
> want to have an exporter Block then great ;) It would also be possible to
add
> a BlockListener that automagiocally published different Blocks into the
ARMI
> exporter.
How about below configuration? But Paul have better idea than me. :-)
-- assembly.xml
<block-listener
class="org.apache.avalon.cornerstone.listeners.armi.ArmiPublisher"
name="armi">
...
...
</block-listner>
<block class="org.apache.avalon.foo.blocks.Bar" name="barbar">
...
</block>
-- config.xml
<armi>
<publish name="Bar">
<block>barbar</block>
<interface>org.apache.avalon.foo.services.Bar1</interface>
<interface>org.apache.avalon.foo.services.Bar2</interface>
</publish>
<publish name="X1">
...
</publish>
</armi>
>
> I don't have time to play atm but it sounds neat.
> --
> Cheers,
>
> Pete
>
> -----------------------------------------------------------
> If your life passes before your eyes when you die,
> does that include the part where your life passes before
> your eyes?
> -----------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Peter Donald <pe...@apache.org>.
On Mon, 7 Jan 2002 09:55, Paul Hammant wrote:
> 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)
im not surprised ;)
> 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'.
one of the joys of commons. People who don't work on the code get voting
rights. Fun - aint it?
> 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.
I don't think it is time to put it inside the Phoenix "kernel" just yet and
have not yet reached a stable point in ClassLoader etc arrangement. If you
want to have an exporter Block then great ;) It would also be possible to add
a BlockListener that automagiocally published different Blocks into the ARMI
exporter.
I don't have time to play atm but it sounds neat.
--
Cheers,
Pete
-----------------------------------------------------------
If your life passes before your eyes when you die,
does that include the part where your life passes before
your eyes?
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Ann] Labrador 0.2 (Was Armi - Alternate to RMI (Commons-scratchpad))
Posted by Paul Hammant <Pa...@yahoo.com>.
Tom,
>> I guess Tom, out of politeness I should learn more about Labrador
>> (rather that just hope I can write a Labrador transport for ARMI..
>
>
> Yes, you absolutely should.
>
> <snip>
I''ve just been looking at it (from CVS).
*Similarities*.
You are publishing on a similar basis to Glue and ARMI. Glue and ARMI
have 'publish(Object bean)' you have 'register(Object bean)'. Glue and
ARMI overload that with 'publish(Object bean, Class[]
onlyTheseInterfaces)' You may want to think about the interface
filtering that the other two do.
*Differences*
The client code for Labrador depends on XMLRPC (currently). This is
snipped from your docs:
String url = "http://localhost:1980/xmlrpc/test";
XmlRpcClient client = new XmlRpcClient(url);
Vector v = new Vector();
v.add(args[0]);
System.out.println(client.execute("hello", v));
This so sucks it is unbelievable. It is not your fault dude of course
dude as that is a third party lib (yes I know it is at Apache). ARMI is
directly inspired by Glue which I will credit with the novelties :
String url = "http://localhost:1980/xmlrpc/test";
MyAutoClassInterface myac = (MyAutoClassInterface) ARMIorGlue.lookup(url);
System.out.println(myac.hello(args[0]));
Has XML-RPC code been tested for speed? E.G. 100,000 iterations of the hello method as listed
Glue is first class in that it represents an interface remotely. Fully.
Granted in your example, there is no MyAutoClassInterface (there is
only MyAutoClass). As such there could be no prepackaged jar of
interfaces for the MyAutoClass service pre-existing on the client
machine. With ARMI I plan to pump the lot on demand.
ARMI unlike Glue and Labrador recognoses that some method calls in the
primary (or any) service might create connections to other services. As
such it is a blend of pass by value and pass by reference. It's niche
at the moment is Facade publishing for 100% Java solutions
*Marshalling*
You opted for a custom marshalling scheme that can be tacked onto a HTTP
request/reply. You're using a real temporary file, but I guess that is
a temporary solution? You've done a huge amount of work on difficult
things like XML Documents etc. This is really cool and I may at some
point crib the code (whilst crediting fully its source).
*Integrations*
You have a servlet adaptor that will allow publishing via third party
tools like Tomcat, Jo!, or Resin. This is very cool. Full on
webservice. You also have a tiny HTTP server built in that should allow
the minimal required to punch through firewalls. Both I guess will form
the basis for full SOAP compatability. Again I think I should be
inspired here.
> Regarding XML-Commons... I've been seeing a lot of overlap lately
> between some of the things going on in Jakarta and in XML. There
> should probably be a concerted effort for everybody to get on the same
> page and consolidate things. The packages should just be called
> "Commons" and be shared between all of the projects.
+1
> As far as Labrador is concerned, I'll keep plugging along with it
> until people take notice and see the value in it. There's probably a
> bit of overlap between Labrador and ARMI, only problem being that
> Labrador isn't being managed under the Apache umbrella.
There is overlaps as you say between ARMI and Labrador.
If I could summarise the differences:
ARMI - For 100% Java solutions. Full & near seamless interface or
facade publishing
Labrador - Clients can be multi language. Integrations with Third Party
Webservers.
A future?
I sure there is a possibility for merge or something....
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Ann] Labrador 0.2 (Was Armi - Alternate to RMI (Commons-scratchpad))
Posted by Tom Bradford <br...@dbxmlgroup.com>.
On Sunday, January 6, 2002, at 04:45 PM, Paul Hammant wrote:
> I guess Tom, out of politeness I should learn more about Labrador
> (rather that just hope I can write a Labrador transport for ARMI..
Yes, you absolutely should.
I've just released Labrador 0.2. To quote the README:
The 0.2 version of the Labrador XML Object Broker introduces better type
conversions, better array support, lots of bug fixes, and an internal
HTTP Server. Still no SOAP support, but it should be ready by version
0.5. Also, still no DateTime support, which you can expect in 0.3.
You can find Labrador as well as some examples of using it at:
http://xml-labrador.sourceforge.net
Regarding XML-Commons... I've been seeing a lot of overlap lately
between some of the things going on in Jakarta and in XML. There should
probably be a concerted effort for everybody to get on the same page and
consolidate things. The packages should just be called "Commons" and be
shared between all of the projects.
As far as Labrador is concerned, I'll keep plugging along with it until
people take notice and see the value in it. There's probably a bit of
overlap between Labrador and ARMI, only problem being that Labrador
isn't being managed under the Apache umbrella.
--
Tom Bradford - http://www.tbradford.org
Developer - Apache Xindice (Native XML Database)
Creator - Project Labrador (XML Object Broker)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Paul Hammant <Pa...@yahoo.com>.
Tom,
>> 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'.
>
>
> I received some similar disapproval from the XML folks regarding
> Labrador being positioned as the common architecture for Axis and
> XML-RPC. It's unfortunate, because if we could all sit down as a
> group, we could nail down a common architecture for getting all of
> these architectures working and playing together SOAP/Axis, XML-RPC,
> RMI, ARMI, and Labrador. Instead, the only thing I heard was "Why do
> we need another broker?"
Yup it's a good point. As it happens AMRI enshrines the multiple
transport concept. I could write adaptors that make use of (I hope)
Labrador, XML-RPC, Axis. Of course I'd not want to take away from those
projects ability to run standalone.
In direct anwer to your request for a "common architecture for getting
all of these architectures working together" I think the lowest common
denominator is a Java interface (any java interface - think
ActionListener & ActionEvent). It is that that ARMI publishes. No
extra baggage like RMI. Within the context of IoC and accessed through
ComponentManager it it implementation hidden from the user. They truely
don't know where the remote resource is or how it was accessed.
I guess Tom, out of politeness I should learn more about Labrador
(rather that just hope I can write a Labrador transport for ARMI..
> Oh well. I'm going to release 0.2 today if SourceForge ever comes
> back up (http://xml-labrador.sourceforge.net).
Do you want to try Commons? There is a commons for xml.apache.org that
is the couterpart to Jakarta's one.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Armi - Alternate to RMI (Commons-scratchpad)
Posted by Tom Bradford <br...@dbxmlgroup.com>.
On Sunday, January 6, 2002, at 03:55 PM, Paul Hammant wrote:
> 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'.
I received some similar disapproval from the XML folks regarding
Labrador being positioned as the common architecture for Axis and
XML-RPC. It's unfortunate, because if we could all sit down as a group,
we could nail down a common architecture for getting all of these
architectures working and playing together SOAP/Axis, XML-RPC, RMI,
ARMI, and Labrador. Instead, the only thing I heard was "Why do we need
another broker?"
Oh well. I'm going to release 0.2 today if SourceForge ever comes back
up (http://xml-labrador.sourceforge.net).
--
Tom Bradford - http://www.tbradford.org
Developer - Apache Xindice (Native XML Database)
Creator - Project Labrador (XML Object Broker)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>