<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<body link="#355491" alink="#4262a1" vlink="#355491" style="background: #e2e2e2; margin: 0; padding: 20px;">
<div>
<table cellpadding="0" bgcolor="#FFFFFF" border="0" cellspacing="0" style="border: 1px solid #dadada; margin-bottom: 30px; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td>
<table border="0" cellpadding="0" cellspacing="0" bgcolor="#FFFFFF" style="border: solid 2px #ccc; background: #dadada; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td bgcolor="#000000" valign="middle" height="58px" style="border-bottom: 1px solid #ccc; padding: 20px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -webkit-border-top-right-radius: 5px; -webkit-border-top-left-radius: 5px;">
<h1 style="color: #333333; font: bold 22px Arial, Helvetica, sans-serif; margin: 0; display: block !important;">
<!-- To have a header image/logo replace the name below with your img tag -->
<!-- Email clients will render the images when the message is read so any image -->
<!-- must be made available on a public server, so that all recipients can load the image. -->
<a href="http://community.jboss.org/index.jspa" style="text-decoration: none; color: #E1E1E1">JBoss Community</a></h1>
</td>
</tr>
<tr>
<td bgcolor="#FFFFFF" style="font: normal 12px Arial, Helvetica, sans-serif; color:#333333; padding: 20px; -moz-border-radius-bottomleft: 4px; -moz-border-radius-bottomright: 4px; -webkit-border-bottom-right-radius: 5px; -webkit-border-bottom-left-radius: 5px;"><h3 style="margin: 10px 0 5px; font-size: 17px; font-weight: normal;">
Re: IIOP Subsystem Issues
</h3>
<span style="margin-bottom: 10px;">
created by <a href="http://community.jboss.org/people/sguilhen">Stefan Guilhen</a> in <i>JBoss AS7 Development</i> - <a href="http://community.jboss.org/message/602827#602827">View the full discussion</a>
</span>
<hr style="margin: 20px 0; border: none; background-color: #dadada; height: 1px;">
<div class="jive-rendered-content"><p>Thanks for the reply, David.</p><blockquote class="jive-quote"><p>David Lloyd wrote:</p><p style="min- padding: 0px;">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 <strong>all</strong> of these config items be configurable via the central configuration mechanism. </p></blockquote><p>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.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><blockquote class="jive-quote"><p>David Lloyd wrote:</p>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.</blockquote><p>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.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><blockquote class="jive-quote">David Lloyd wrote:<br/>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:<ol><li>Make sure you have a proper thread name which is descriptive.</li><li>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 <strong>huge</strong> 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.</li><li>Your stop method, like start(), cannot block.  This means that it must do the following: <ol><li>Upon entry, call context.asynchronous().</li><li>Signal the thread that it must terminate, passing the context to it in a deterministic fashion.</li><li>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).</li></ol></li><li>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.</li></ol></blockquote><p>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.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><blockquote class="jive-quote"><code class="jive-code"></code><code class="jive-code"></code><p>David Lloyd wrote:</p><p>First I would verify that the "system" module is <strong>not</strong> 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.</p></blockquote><p>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.</p></div>
<div style="background-color: #f4f4f4; padding: 10px; margin-top: 20px;">
<p style="margin: 0;">Reply to this message by <a href="http://community.jboss.org/message/602827#602827">going to Community</a></p>
<p style="margin: 0;">Start a new discussion in JBoss AS7 Development at <a href="http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2225">Community</a></p>
</div></td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>