1 2 Previous Next 22 Replies Latest reply on May 20, 2011 2:17 PM by sguilhen

    IIOP Subsystem Issues

    sguilhen

      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.

        • 1. IIOP Subsystem Issues
          dmlloyd

          I'll answer the issues inline.

           

          Stefan Guilhen wrote:

           

          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?

          The file should not really be anywhere.  We need a better way to configure the ORB - either by hooking into its configuration mechanism or in the worst case feeding it a programmatically generated properties file.  It is very important that all of these config items be configurable via the central configuration mechanism.

           

           

          Stefan Guilhen wrote:

           

          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?

           

          That's the right way to work around this type of problem.  I think ultimately though we want to fix these issues in the upstream projects, pushing those fixes upstream if possible.  The rule is, if the project is loading its own implementation classes they should usally be loaded directly using its own class loader by default.  It also usually makes sense to have a variant which accepts a class loader argument as well.

           

           

          Stefan Guilhen wrote:

           

          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?

           

          If a service requires a dedicated thread, then creating a thread is exactly the right thing to do.  To do this from MSC properly though, you should:

          1. Make sure you have a proper thread name which is descriptive.
          2. Your start method should return when it is clear that the service started successfully. When you start up a thread this gets tricky though because the thread could start up and then a failure could become known only from within the thread! Since blocking in start() is a huge no-no, you cannot use conditions or latches or anything like that to verify your thread start. Instead you will probably have to use the asynchronous start mechanism. I'd recommend that you call context.asynchronous() early in the start method, call context.complete() or context.failed() from the thread once you know everything is OK (or not), and judiciously employ try/finally in start() to ensure that either the thread starts successfully or context.failed() is called.
          3. Your stop method, like start(), cannot block.  This means that it must do the following:
            1. Upon entry, call context.asynchronous().
            2. Signal the thread that it must terminate, passing the context to it in a deterministic fashion.
            3. The thread must call context.complete() when the ORB is known to be stopped (see the thread pool services for an example of this behavior).
          4. Make sure that there is no code path that would allow start() or stop() to be called without complete() or failed(), else the container may hang.

           

           

          It does raise a question about thread services - if we end up needing more than one of these, we may want to explore a generalized ThreadService base class which creates and manages a thread, or something like that.  But for now let's just do it the simple way.

           

           

          Stefan Guilhen wrote:

           

          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.

           

          First I would verify that the "system" module is not among the list of imports for the jacorb module or any of its transitives; this is the simplest possible explanation for the problem you see.  Using endorsed is definitely not something we want to do.  I'm pretty sure though that the problem you're seeing is due to using the "system" module.  Removing org.omg and its children from javax.api and adding an new org.omg.api module is definitely the right thing to do.

          • 2. IIOP Subsystem Issues
            dmlloyd

            Also, you're going to need to override the javax.rmi.CORBA API as well.  I hope JacORB has one of those!

            • 3. IIOP Subsystem Issues
              dmlloyd

              Actually you need to replace the javax.rmi package as well.  The JDK javax.rmi.ssl package is probably fine though.

              • 4. IIOP Subsystem Issues
                sguilhen

                Thanks for the reply, David.

                David Lloyd wrote:

                The file should not really be anywhere.  We need a better way to configure the ORB - either by hooking into its configuration mechanism or in the worst case feeding it a programmatically generated properties file.  It is very important that all of these config items be configurable via the central configuration mechanism.

                This is probably ok. The IIOP subsystem allows for generic properties to be specified, so I can move the props defined in jacorb.properties directly to the subsystem configuration and remove the file.

                 

                 

                David Lloyd wrote:

                That's the right way to work around this type of problem.  I think ultimately though we want to fix these issues in the upstream projects, pushing those fixes upstream if possible.  The rule is, if the project is loading its own implementation classes they should usally be loaded directly using its own class loader by default.  It also usually makes sense to have a variant which accepts a class loader argument as well.

                Good, I'll leave the code as it is right now. I can probably set the classloader as one of the properties used to init the ORB and change JacORB's init implementation to check for this classloader and use it instead of the thread context CL.

                 

                David Lloyd wrote:
                If a service requires a dedicated thread, then creating a thread is exactly the right thing to do.  To do this from MSC properly though, you should:
                1. Make sure you have a proper thread name which is descriptive.
                2. Your start method should return when it is clear that the service started successfully. When you start up a thread this gets tricky though because the thread could start up and then a failure could become known only from within the thread! Since blocking in start() is a huge no-no, you cannot use conditions or latches or anything like that to verify your thread start. Instead you will probably have to use the asynchronous start mechanism. I'd recommend that you call context.asynchronous() early in the start method, call context.complete() or context.failed() from the thread once you know everything is OK (or not), and judiciously employ try/finally in start() to ensure that either the thread starts successfully or context.failed() is called.
                3. Your stop method, like start(), cannot block.  This means that it must do the following:
                  1. Upon entry, call context.asynchronous().
                  2. Signal the thread that it must terminate, passing the context to it in a deterministic fashion.
                  3. The thread must call context.complete() when the ORB is known to be stopped (see the thread pool services for an example of this behavior).
                4. Make sure that there is no code path that would allow start() or stop() to be called without complete() or failed(), else the container may hang.

                Flavia told me about the asynchronous way but I didn't really find a good way to implement it. The ORB Thread just calls orb.run() and blocks for the lifetime of the ORB - actually not much happens when run() is called, the thread just waits for a shutdown from another to notify it. I didn't see a good way to call context.complete() since the thread just completes after the whole thing has shut down.

                 

                David Lloyd wrote:

                First I would verify that the "system" module is not among the list of imports for the jacorb module or any of its transitives; this is the simplest possible explanation for the problem you see.  Using endorsed is definitely not something we want to do.  I'm pretty sure though that the problem you're seeing is due to using the "system" module.  Removing org.omg and its children from javax.api and adding an new org.omg.api module is definitely the right thing to do.

                Well, that's a problem. I had to add a dependency to javax.api since JacORB needs the javax.rmi.CORBA.Stub class (and maybe some other classes from the javax.rmi package). It doesn't define it's own version of those classes.

                • 5. IIOP Subsystem Issues
                  jason.greene

                  David Lloyd wrote:

                   

                  Actually you need to replace the javax.rmi package as well.  The JDK javax.rmi.ssl package is probably fine though.

                   

                  That will probably break the JSR-160 stuff. Whats the reason for replace javax.rmi?

                  • 6. IIOP Subsystem Issues
                    jason.greene

                    David Lloyd wrote:

                    First I would verify that the "system" module is not among the list of imports for the jacorb module or any of its transitives; this is the simplest possible explanation for the problem you see.  Using endorsed is definitely not something we want to do.  I'm pretty sure though that the problem you're seeing is due to using the "system" module.  Removing org.omg and its children from javax.api and adding an new org.omg.api module is definitely the right thing to do.

                    Well, that's a problem. I had to add a dependency to javax.api since JacORB needs the javax.rmi.CORBA.Stub class (and maybe some other classes from the javax.rmi package). It doesn't define it's own version of those classes.

                     

                    javax.api is ok, it's system that causes the problem. However, like david mentioned we need to replace the org.omg that javax.api is using by modifying the javax.api.

                    • 7. IIOP Subsystem Issues
                      jason.greene

                      Jason Greene wrote:

                       

                      David Lloyd wrote:

                       

                      Actually you need to replace the javax.rmi package as well.  The JDK javax.rmi.ssl package is probably fine though.

                       

                      That will probably break the JSR-160 stuff. Whats the reason for replace javax.rmi?

                       

                      Ah, to answer my own question, corba stubs are going to see the jdk's org.omg. Hmm I can't see a way out of JSR-160 aside from forking the 160 impl in the jdk.

                      • 8. IIOP Subsystem Issues
                        dmlloyd

                        Jason Greene wrote:

                         

                        Jason Greene wrote:

                         

                        David Lloyd wrote:

                         

                        Actually you need to replace the javax.rmi package as well.  The JDK javax.rmi.ssl package is probably fine though.

                         

                        That will probably break the JSR-160 stuff. Whats the reason for replace javax.rmi?

                         

                        Ah, to answer my own question, corba stubs are going to see the jdk's org.omg. Hmm I can't see a way out of JSR-160 aside from forking the 160 impl in the jdk.

                        It's always something!

                        • 9. IIOP Subsystem Issues
                          dmlloyd

                          Stefan Guilhen wrote:

                           

                          Flavia told me about the asynchronous way but I didn't really find a good way to implement it. The ORB Thread just calls orb.run() and blocks for the lifetime of the ORB - actually not much happens when run() is called, the thread just waits for a shutdown from another to notify it. I didn't see a good way to call context.complete() since the thread just completes after the whole thing has shut down.

                          It looks like ORB.destroy() might block until the thread is shut down?  If so, you could use another thread - or a thread pool - to shut it down and hit the callback when it completes?

                           

                           

                          Stefan Guilhen wrote:

                          David Lloyd wrote:

                          First I would verify that the "system" module is not among the list of imports for the jacorb module or any of its transitives; this is the simplest possible explanation for the problem you see.  Using endorsed is definitely not something we want to do.  I'm pretty sure though that the problem you're seeing is due to using the "system" module.  Removing org.omg and its children from javax.api and adding an new org.omg.api module is definitely the right thing to do.

                          Well, that's a problem. I had to add a dependency to javax.api since JacORB needs the javax.rmi.CORBA.Stub class (and maybe some other classes from the javax.rmi package). It doesn't define it's own version of those classes.

                           

                          OK yeah like Jason said I didn't mean javax.api, which is among the few modules which correctly depends on "system".  I think at the moment it's safe to say that any module in the current upstream tree with a dependency on "system" has it for a good reason (and filters it down as appropriate). The important takeaway is, remove the CORBA stuff from the list of filters in javax.api before introducing your own API.

                          • 10. IIOP Subsystem Issues
                            sguilhen

                            David Lloyd wrote:


                            It looks like ORB.destroy() might block until the thread is shut down?  If so, you could use another thread - or a thread pool - to shut it down and hit the callback when it completes?

                            That's true. I will make stop() asynchronous and create a thread that calls back the context once the ORB shutdown process has completed. I will leave start() synchrounous as the ORB thread will block for the lifetime of the ORB, so I won't be able to call context.complete() until after the ORB process has been terminated.

                             

                            David Lloyd wrote:

                             

                            OK yeah like Jason said I didn't mean javax.api, which is among the few modules which correctly depends on "system".  I think at the moment it's safe to say that any module in the current upstream tree with a dependency on "system" has it for a good reason (and filters it down as appropriate). The important takeaway is, remove the CORBA stuff from the list of filters in javax.api before introducing your own API.

                             

                            I did that (may not have done it properly though). I've removed all org.omg entries from the javax.api list of filters and introduced a new org.omg.api that depends on jacorb and exports only the org.omg API. But jacorb depends on javax.rmi.CORBA, so it has a dependency on javax.api and apparently the CORBA.Stub class sees the JDK org.omg classes and this ends up producing the VerifyError I've posted before.

                            • 11. IIOP Subsystem Issues
                              dmlloyd

                              Stefan Guilhen wrote:

                               

                              I did that (may not have done it properly though). I've removed all org.omg entries from the javax.api list of filters and introduced a new org.omg.api that depends on jacorb and exports only the org.omg API. But jacorb depends on javax.rmi.CORBA, so it has a dependency on javax.api and apparently the CORBA.Stub class sees the JDK org.omg classes and this ends up producing the VerifyError I've posted before.

                               

                              Okay that explains a lot.  We're going to have to create our own javax.rmi and javax.rmi.CORBA packages.  Can you look into extracting those from OpenJDK and setting up an independent module for them?

                              • 12. Re: IIOP Subsystem Issues
                                sguilhen

                                Ok, I've taken a look into the open JDK code and there is a corba module there that has all the org.omg and javax.rmi.corba classes. Here's what I will try to do: extract the javax.rmi classes and compile them using jacorb's org.omg classes, then do the following with modules:

                                 

                                - create a javax.rmi.api module with this new jar that depends on the org.omg.api jar

                                - make jacorb depend on the new javax.rmi.api module instead of javax.api

                                - remove javax.rmi from javax.api

                                 

                                Does this approach look ok?

                                • 13. IIOP Subsystem Issues
                                  sguilhen

                                  I've tried what my previous post suggested and the issue is gone. So now I have a small project that compiles the javax.rmi and javax.rmi.CORBA packages using JacORB's org.omg API. The question now is where should this new project reside? Along with the other "spec" projects?

                                  • 14. IIOP Subsystem Issues
                                    dmlloyd

                                    Yes.  Create a spec subproject for it.  Make sure you coordinate with Shelly though; it's her project.

                                    1 2 Previous Next