[jboss-dev-forums] [JBoss AS7 Development] - Re: IIOP Subsystem Issues

[Stefan Guilhen]

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&containerType=14&container=2225]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20110429/e41cc17d/attachment.html