The better way is to split out the dynamic iiop stub generation code from
the ORB integration code.
As this case shows, the dynamic stub generation (no ejbc/rmic step during
development) is a useful feature even for people that don't use the all config
with jacorb enabled.
In this case, the user was probably using the JDK orb or some other package?
Just copying jboss-iiop.jar into default is going to confuse people
since now the mbeans are there for jacorb integration but they won't work
because the dependent jars are missing, e.g. jacorb.jar, etc.
Actually I noticed that jboss-iiop.jar was already in server/default/lib (by Scott?)
The dynamic stub generation code seems ORB independent, so yes, maybe it can go in a separate jboss-dynstub.jar.
I don't see why this is needs to be added to the default configuration.
The dynamic generation of IIOP stubs happens at the server side. If IIOP stubs are needed, then there is some IIOP-enabled EJB deployed in the appserver, which is therefore running a configuration with full support to IIOP.
On ORB independence...
The whole IIOP module (jboss-iiop.jar and jboss-iiop-client.jar) should be ORB independent. The main reason it isn't ORB independent is the lack of a standard way of running IIOP over SSL.
Franscisco, in http://jira.jboss.com/jira/browse/JBAS-4927 the user is accessing a remote application using sun rmi-iiop.
Ok, so the problem may be at the client side. The dynamically generated IIOP stubs use classes that live in jboss-iiop-client.jar. Does the user have jboss-iiop-client.jar at the client side?
I suppose JBoss (a jsp/servlet) was acting as a client in this case. But since he had the stub included with the .war, maybe we should just do better error handling trying to create dynamically a new stub without jboss-iiop.jar in the classpath, rather than throwing back an exception.
I finally found some time to actually look at org.jboss.web.tomcat.service.WebAppClassLoader and see that the IIOP stub is now being generated at the client (web app) side. Why can't a web client dynamically get (via HTTP) IIOP stubs generated by the EJB container, like other clients do? This works fine for plain application clients and for EJBs acting as clients, it should work also for web clients.
The WebAppClassLoader dependency on the IIOPStubCompiler looks unnecessary (and bad) to me. I understand that dependency was introduced to fix JBCTS-591 and JBCTS-609, but IMO the right way of fixing those issues is to ensure that the webapp classloader sees the auxiliary classes used by the container-generated stubs (i.e., jboss-iiop-client.jar).
Francisco, I think that downloading stubs via HTTP is not applicable in this case because the stubs are generated by the RI, and are available in the web app war file that is deployed on JBoss. Thus, I don't think the RI's IORs include a codebase URL to indicate where to download the stubs from.
This brings us to another discussion: why WebAppClassLoader has to dynamically generate stubs that are already available in the wep app war file? After taking another look at issues JBCTS-591 and JBCTS-609, I have to agree with Francisco that the dependency on IIOPStubCompiler looks unnecessary, as the WebAppClassLoader should be able to load the stub classes from the deployed war file.