In the process of implementing the IIOP Subsystem along with the JacORB integration I've run into a few issues that probably need some discussing, so I will enumerate the problems here to have a record of them.
As of now, the IIOP Subsystem can be started in standalone mode. It configures and bootstraps the JacORB ORB, Root POA (bound under jboss/orb and jboss/poa respectively) and starts the CORBA naming service if a tweaked JacORB version is used. This is the link to the commit: https://github.com/sguilhen/jboss-as/commit/ad5cbf87efa9d5dd99ef9f2d83a51d4731e8b85f
Issue 1 - JacORB configuration file
When bootstraping the ORB, jacorb.properties must be loaded by the ORB service. My initial approach was to place the jacorb.properties file under standalone/configuration (along with the logging.properties file), inject the jboss.server.config.dir into the ORB service and then read the configuration file as a regular file. Although this approach works in standalone mode, it fails in the domain mode because jboss.server.config.dir points to the configuration dir of each server and not to domain/configuration. As a result, the file can't be loaded and the ORB doesn't start as it should.
In a nutshell, this initial approach doesn't look like the right thing to do. What would be the right way for reading jacorb.properties? If the file was immutable I could probably place it in the META-INF dir of the IIOP module and load it via class loader. However, jacorb.properties must be available for easy editing - users might, for example, enable SSL socket factories for IIOP by setting the appropriate option in jacorb.properties. So where should this file be placed and how do we load it?
Issue 2 - ORB related classes are instantiated via context classloader
The ORB is created by calling the static ORB.init(String[], Hashtable) method. This method attempts to instantiate the ORB class and all its initializers by using the Thread context classloader. As a result, if we don't set the context classloader before calling init we get CNFEs. So here's what I did to get around it:
ClassLoader loader = SecurityActions.getThreadContextClassLoader();
try {
SecurityActions.setThreadContextClassLoader(SecurityActions.getClassLoader(this.getClass()));
this.orb = ORB.init(new String[0], properties);
} finally {
// restore the thread context classloader.
SecurityActions.setThreadContextClassLoader(loader);
}
I temporarily set the thread context classloader to use the same classloader of the IIOP subsystem module. This way all classes are successfully loaded and the ORB is initialized without errors. Does this look ok or do do you have any other suggestions for doing this?
Issue 3 - The ORB must run in a dedicated thread
The ORB.run() method must be placed in a dedicated thread as this call blocks the current thread for the lifetime of the ORB. This means the service thread that is starting the ORB service would block until the ORB receives a shutdown message. What I'm currently doing is creating a new Thread and setting a runnable that runs the ORB but this is clearly not the right way to do this . I imagine the server has some control over its threads and a service shouldn't be creating new threads like this. Is there a thread service I can call to create a thread that is managed by the server?
Issue 4 - JacORB has linkage problems with JDK classes
If you inspect the code, you will notice that the CORBA naming service is not being installed (see the commented out code in IIOPSubsystemAdd). That's because calling methods on the running ORB results in a VerifyError:
16:42:40,285 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-15) MSC00001: Failed to start service jboss.iiop.naming-service: org.jboss.msc.service.StartException in service jboss.iiop.naming-service: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1696)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.VerifyError: (class: org/jacorb/orb/Delegate, method: getReference signature: (Lorg/jacorb/poa/POA;)Lorg/omg/CORBA/portable/ObjectImpl;) Incompatible object argument for function call
at org.jacorb.orb.ORB.getReference(Unknown Source)
at org.jacorb.poa.POA.getReference(Unknown Source)
at org.jacorb.poa.POA.create_reference_with_id(Unknown Source)
at org.jboss.as.iiop.service.CorbaNamingService.start(CorbaNamingService.java:77)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
... 3 more
Setting the -noverify option in standalone.conf shows the following:
16:44:48,280 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC00001: Failed to start service jboss.iiop.naming-service: org.jboss.msc.service.StartException in service jboss.iiop.naming-service: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1696)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.AbstractMethodError: org.omg.CORBA.portable.ObjectImpl._set_delegate(Lorg/omg/CORBA/portable/Delegate;)V
at org.jacorb.orb.Delegate.getReference(Unknown Source)
at org.jacorb.orb.ORB.getReference(Unknown Source)
at org.jacorb.poa.POA.getReference(Unknown Source)
at org.jacorb.poa.POA.create_reference_with_id(Unknown Source)
at org.jboss.as.iiop.service.CorbaNamingService.start(CorbaNamingService.java:77)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
... 3 more
The JacORB and JDK classes are being mixed up even though I've removed the org/omg API from the javax.api module and introduced an org.omg.api module with JacORB's API. After messing around for a while I found out that some JacORB classes were causing the module loader to ask the bootstrap class loader to load the org.omg classes instead of loading the version of these classes from jacorb.jar.
After trying to add jacorb to the JRE endorsed dir with no results, I tried regenerating the JacORB jar in a way that it used its own org.omg classes as it seemed to me that JacORB's classes had references to the JDK classes. Setting the Xbootclasspath or the endorsed dirs when compiling JacORB didn't make any difference, so I went a bit extreme and removed the org.omg classes from the rt.jar - that forced JacORB to use its own version of the org.omg classes and the resulting jar fixes the VerifyError.
The CORBA naming service can be tested by uncommenting the line that prevents the service from being installed in IIOPSubsystemAdd and replacing the jar in the jacorb module for the jar I'm attaching here.
As I'm not a classloading expert I would like other's opinions on this issue.