Re: [ mx4j-Bugs-1200186 ] please revert the -poa change

On Wednesday 11 May 2005 17:25, SourceForge.net wrote:
> https://sourceforge.net/tracker/?func=detail&atid=450647&aid=1200186&group_id=47745
...
> Summary: please revert the -poa change
> 
> Please revert the -poa change introduced in
> build/build.xml (rev 1.96):
> http://sourceforge.net/mailarchive/forum.php?thread_id=5025493&forum_id=8088
> 
> A more detailed description of the problem is attached
> as a plain text file.

To make it easier for subscribers of this list to comment on the
ticket, I'm reposting the bug report here.  It's the same text as can
be found by downloading this file:
http://sourceforge.net/tracker/download.php?group_id=47745&atid=450647&file_id=134086&aid=1200186


==============================================================================
As mentioned in
  http://mail-archive.objectweb.org/carol/2005-05/msg00000.html
  http://www.objectweb.org/wws/arc/carol/2005-05/msg00000.html

I'd like to suggest removing the -poa option from MX4J's build.xml.

Here's why this is a good idea:

 * POA-enabled MX4J doesn't actually work with RMI-IIOP.

 * Sun's JMX Remote RI builds its IIOP ties/stubs without POA.

 * JMX cannot be made to work with POA-flavored CORBA without
   vendor-specific extensions.

I'll elaborate on these three points momentarily.  Before we get to
that, let me present some necessary background information (mostly for
my own benefit -- so that other people can correct gaps in my
understanding of this issue).


What is POA?
------------

POA is a Portable Object Adapter, which is a CORBA-specific piece of
technology.  The definitive source of information on POA is "The
Common Object Request Broker: Architecture and Specification":

  http://www.omg.org/cgi-bin/doc?formal/99-10-07
  http://www.omg.org/cgi-bin/apps/doc?formal/99-10-07.ps.gz

To understand how POA fits or, rather, doesn't fit into MX4J, let's
take a quick look at RMI and CORBA facilities in Java.

To support distributed object systems programming, Java has the notion
of RMI (remote method invocation):
  http://java.sun.com/j2se/1.4.2/docs/guide/rmi/

RMI is a Java-specific piece of distributed object technology which
assumes a homogeneous environment where both clients and servers are
Java programs running in their respective JVMs.

CORBA is also a distributed object systems that allows objects to make
and receive requests and responses in a distributed environment, a
possibly heterogeneous one that mixes Java and non-Java applications:

  http://www.omg.org/gettingstarted/corbafaq.htm#WhatIsIt

Java implements significant chunks of the CORBA specification as
described in
  http://java.sun.com/j2se/1.4.2/docs/api/org/omg/CORBA/doc-files/compliance.html

RMI and CORBA are intertwined in Java in a potentially confusing way.
RMI's original native wire protocol is called JRMP (Java remote
messaging protocol or Java remote method protocol, depending on who
you ask):

   http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol.html

As of JDK 1.3, RMI can also use IIOP (Internet Inter-ORB Protocol) as
its wire protocol:

   http://java.sun.com/j2se/1.3/docs/relnotes/features.html#iiop

RMI-IIOP is a weird cross between pure original RMI and CORBA.  It
kinda sorta uses CORBA underneath, but it's really just RMI:
  http://java.sun.com/j2se/1.3/docs/relnotes/features.html#iiop

In addition to this, Java also supports true CORBA (including Portable
Object Adapters and such).

From the programming standpoint, the difference between RMI-over-IIOP
and CORBA is demonstrated by the following two "Hello world" examples:

  http://java.sun.com/j2se/1.4.2/docs/guide/rmi-iiop/tutorial.html#helloserver
  http://java.sun.com/j2se/1.4.2/docs/guide/rmi-iiop/rmiiiopexample.html#helloserver

I'll refer to the first one as the "RMI-IIOP example" and the second
one as "IIOP-POA example".



POA-enabled MX4J doesn't actually work with IIOP
------------------------------------------------

The test case attached to
  http://mail-archive.objectweb.org/carol/2005-05/msg00000.html
    mx4j-client-server-example-2005-05-11.tar.gz:
      http://www.objectweb.org/wws/arc/carol/2005-05/bin00000.bin

is modeled after Sun's IIOP-POA example.  Note that the test case goes
through all the right motions of instantiating an ORB, obtaining the
root POA from it, and activating the POA.  After our Server.java class
calls RMIConnectorServer#start, the ball lands in the MX4J court.
MX4J tries to bind the (remote) server object into a naming context.
This is done in mx4j.remote.resolver.iiop.Resolver#bindServer.

Here, we run into the first difference between MX4J and Sun's IIOP-POA
example.  In MX4J's case, we put the Remote object itself into the
naming context.  Internally, the JNDI implementation obtains the stub
for our Remote object (RMIServerImpl) and puts the stub into naming
context.

Contrast this with Sun's IIOP-POA example, where instead of binding a
stub we bind an object reference.  The object reference is obtained by
calling the POA#create_reference_with_id on the POA. (It's interesting
to note that the stub class doesn't even have to be present on the
server's classpath for Sun's example to work. It's never used on the
server side in the IIOP-POA case.  However, it _is_ used on the server
side in the RMI-IIOP case.)

Can we do the same thing in MX4J?  Register the object with the POA,
obtain an object reference and all that? Not without going through a
number of motions that strike me as unnatural.  To obtain an object
reference to our Remote RMIServerImpl object, we need access to the
POA -- the same POA that we previously should have used to activate
the remote object via a call to POA#activate_object_with_id or
POA#activate_object.  Does MX4J have a pointer to the right POA?  It
does not.  There doesn't seem to be an API in JMX for passing the POA
around.

True, a recent patch requested by Florent gives us access to the ORB:

  http://sourceforge.net/tracker/index.php?func=detail&aid=1164309&group_id=47745&atid=450647
  http://sourceforge.net/mailarchive/forum.php?thread_id=6830772&forum_id=8088

However, as far as I can tell, having the right ORB doesn't
necessarily enable us to obtain the right POA.  (True, we can get the
root POA, but we can't know for certain whether the Remote object was
activated by the root POA or one of its children or grandchildren.
Therefore, being able to obtain the root POA buys us nothing.)

There are other differences between MX4J and Sun's IIOP-POA example
that I won't go into.  To convince yourself that Sun's example is
fairly representative of how things are done in CORBA, check out the
JacORB Programming Guide.  The example on page 19 goes through similar
gyrations: http://www.jacorb.org/docs/ProgrammingGuide_1_4_1.pdf)

These differences lead me to believe that MX4J's current
implementation cannot possibly work with POA.  It certainly doesn't
work with MX4J's own RMI-IIOP example as reported in

  http://sourceforge.net/tracker/index.php?func=detail&aid=1200178&group_id=47745&atid=450647
  http://sourceforge.net/tracker/download.php?group_id=47745&atid=450647&file_id=134083&aid=1200178




Sun's JMX Remote RI builds its IIOP ties/stubs without POA
----------------------------------------------------------

Sun's JMX Remote Reference Implementation, available from
http://java.sun.com/products/JavaManagement/download.html, does _not_
build its IIOP ties/stubs with -poa.  To verify this for yourself, try
the following:

| $ javap -classpath jmxremote.jar \
|    org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie |
|   grep extends | sed 's/.*extends //' | sed 's/ implements.*//'
| org.omg.CORBA_2_3.portable.ObjectImpl

Now try the same thing with MX4J 3.0.1

| $ javap -classpath mx4j-remote.jar \
|   org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie |
|   grep extends | sed 's/.*extends //' | sed 's/ implements.*//'
| org.omg.PortableServer.Servant

Note that in Sun's case, _RMIServerImpl_Tie extends
org.omg.CORBA_2_3.portable.ObjectImpl, whereas in the MX4J case, it
extends org.omg.PortableServer.Servant.  This means the latter has
been the generated with the -poa flag and the former without one.

If MX4J wants to be feature-for-feature (and bug-for-bug) compatible
with Sun's implementation, the -poa flag has to go.


JMX cannot be made to work with POA-flavored CORBA
--------------------------------------------------

I believe it would be possible to make MX4J work with POA, but only at
the cost of introducing MX4J-specific extensions.  The JMX API doesn't
provide a way for passing POA around.



Does anybody depend on the MX4J current brokeness?
--------------------------------------------------

I don't know the answer to this question and I'd like to find out.
The -poa option was added about a year ago (2004-06-29) in
build/build.xml (rev. 1.96):

  http://sourceforge.net/mailarchive/forum.php?thread_id=5025493&forum_id=8088

It was added at the request of David Robinson (kc7bfi) who claimed
that stubs generated without the -poa flag prevented MX4J from working
with JacORB:

  http://sourceforge.net/mailarchive/message.php?msg_id=8767261
  http://sourceforge.net/mailarchive/forum.php?thread_id=4973667&forum_id=8174
  http://sourceforge.net/mailarchive/message.php?msg_id=8834373


David wrote:

|  "When trying to use mx4j with jacORB I have a problem that the
|  stubs generated with rmic generate the iiop interface but not the
|  poa interface. JacORB no longer support the BOA (used by the -iiop)
|  and requires the POA (generated by the -poa option)."

I don't think this characterization is entirely accurate.  This makes
it sound like our choice is between BOA (Basic Object Adapter) and POA
(Portable Object Adapter).  That is incorrect.  There are three
choices:

  - RMI-over-IIOP
  - BOA
  - POA

BOA is now deprecated.  J2SE never shipped BOA -- Sun went straight to
the newer POA model.  So, when you compile your stubs/ties with "rmic
-iiop", you're committing to the RMI-IIOP model which is a mildly
CORBA-flavored kind of RMI.  When you compile your ties/stubs with
"rmic -iiop -poa", you're committing to the true full-blown CORBA
model.

So, Sun's rmic gives you a choice between RMI-IIOP and POA-based
CORBA.  It does _not_ give you a choice between BOA and POA.  BOA is
not part of this picture at all.

So, by using "rmic -iiop -poa", we're committing to a true CORBA
model.   However, as far as I can tell, JMX Remote is not designed to
work with true CORBA.  Not out of the box, anyway. There was a JSR
that attempted to do this but it was withdrawn:

  http://www.jcp.org/en/jsr/detail?id=70

The only piece of software known to me that has ever claimed to mix
MX4J and true CORBA (seemingly) successfully is the SNMP Trap to CORBA
Notification Service:

  http://snmptrapnotify.sourceforge.net/

That's a piece of software developed by David Robinson -- the same one
who requested MX4J to be built with -poa.

How does snmptrapnotify deal with the obstacles outlined above?  As
far as I can tell, by introducing vendor-specific extensions. See

 http://snmptrapnotify.sourceforge.net/xref/com/orci/snmptrapnotify/MainApp.html

I direct your attention to following lines

186 | HashMap environment = new HashMap();
187 | environment.put("mx4j.rmi.IIOPREsolver.ORB", orb);
188 | environment.put("mx4j.rmi.IIOPREsolver.POA", poa);
189 | org.jacorb.orb.rmi.PortableRemoteObjectDelegateImpl.setORB(orb);
190 | JMXServiceURL address = new JMXServiceURL("service:jmx:iiop://localhost/jndi/jmxSnmpTrapNotify");

Note that the ORB is passed to MX4J by putting it in the environment
map.  This is non-standard.  The standard mechanism was pointed out by
Florent in
  http://sourceforge.net/tracker/index.php?func=detail&aid=1164309&group_id=47745&atid=450647

and is described in
  http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/rmi/package-summary.html

The POA is passed to MX4J in a similar non-standard manner.  I'm not
even sure how this works, because I don't believe MX4J has (or had)
any code that expects POA to be passed.  The latest release of
snmptrapnotify seems to be using MX4J 2.0.1 (2.0.1a, to be precise).
I checked out the sources for that release:

| $ cvs -z3 \
|   -d:pserver:[email protected]:/cvsroot/mx4j \
|   co -r MX4J_2_0_1 -P mx4j

There isn't any code that deals with POA:

 | $ find mx4j/ -name \*.java | xargs grep POA | wc -l
 | 0

So, as far as can tell, the quoted chunk of code in
com.orci.snmptrapnotify.MainApp is either meaningless, or depends on a
custom build of MX4J 2.0.1.

Finally, the setORB call in
PortableRemoteObjectDelegateImpl.setORB(orb) is JacORB-specific.  As
you can check for yourself, the
javax.rmi.CORBA.PortableRemoteObjectDelegate interface doesn't declare
the setORB(ORB) method:
  http://java.sun.com/j2se/1.4.2/docs/api/javax/rmi/CORBA/PortableRemoteObjectDelegate.html

In other words, snmptrapnotify is tied to a specific CORBA
implementation -- it's not coded strictly against public CORBA APIs.

To sum up, the only known user of the POA-enabled MX4J stubs is an
application that has a vendor-specific dependency on JacORB and likely
uses a custom, patched up build of MX4J.

Are there any others?


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id281&op=click