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

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.

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.

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.

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.