4:17 p.m.
Stefan Guilhen [http://community.jboss.org/people/sguilhen] created the discussion
"IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602805#602805
--------------------------------------------------------------
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/ad5cbf87efa9d5dd99ef9f2d83a51...
https://github.com/sguilhen/jboss-as/commit/ad5cbf87efa9d5dd99ef9f2d83a51...
*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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602805#602805]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
4:51 p.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602809#602809
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602809#602809]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
6:45 p.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602820#602820
--------------------------------------------------------------
Also, you're going to need to override the javax.rmi.CORBA API as well. I hope JacORB
has one of those!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602820#602820]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
6:48 p.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602821#602821
--------------------------------------------------------------
Actually you need to replace the javax.rmi package as well. The JDK javax.rmi.ssl package
is probably fine though.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602821#602821]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
11 p.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
Jason Greene [http://community.jboss.org/people/jason.greene] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602830#602830
--------------------------------------------------------------
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?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602830#602830]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
11:07 p.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
Jason Greene [http://community.jboss.org/people/jason.greene] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602832#602832
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602832#602832]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
2:38 p.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602862#602862
--------------------------------------------------------------
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!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602862#602862]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
9:30 p.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
Stefan Guilhen [http://community.jboss.org/people/sguilhen] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602827#602827
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602827#602827]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
11:04 p.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
Jason Greene [http://community.jboss.org/people/jason.greene] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602831#602831
--------------------------------------------------------------
> 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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602831#602831]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
3:40 p.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/602865#602865
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/602865#602865]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
10:41 a.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
Stefan Guilhen [http://community.jboss.org/people/sguilhen] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/603036#603036
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/603036#603036]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
10:49 a.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/603040#603040
--------------------------------------------------------------
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?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/603040#603040]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
10:23 a.m.
New subject: [JBoss AS7 Development] - Re: IIOP Subsystem Issues
Stefan Guilhen [http://community.jboss.org/people/sguilhen] created the discussion
"Re: IIOP Subsystem Issues"
To view the discussion, visit: http://community.jboss.org/message/604240#604240
--------------------------------------------------------------
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 approach look ok?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/604240#604240]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
4733
days inactive
4743
days old
jboss-dev-forums@lists.jboss.org
12 comments
3 participants
participants (3)
-
David Lloyd -
Jason Greene
-
Stefan Guilhen