Sahoo wrote:
> I am concerned about overuse of names in our code for important
> operations. I see three kinds of names being used:
> 1. service names used in looking up objects in environment (habitat).
> 2. classnames used to load classes dynamically. e.g. container name in
> Sniffer
> 3. module names used to load modules.
>
> First of all, they are hardly defined as constants. Secondly, there is
> too much dynamism in the code. I am afraid this may lead to
> maintenance issues in future.
>
As I have been pointing out for months now, much of the ORB
configuration is dynamic, and has been that
way for a decade (not really a maintenance concern in my experience
compared to everything else).
The CORBA standards that we implement require this, as they are all
based on standard Java properties.
Our internal CORBA SPI follows this pattern as well.
I am much more concerned with the difficulties OSGi creates in this
regard. Basically all of the ClassLoader.loadClass
usages look like forbidden access to a private class. For example,
the EJB code needs to use an instance of
com.sun.corba.ee.spi.orb.ORBConfigurator (defined in glassfish-corba-orb)
defined in PEORBConfigurator (which is private in the orb-iiop bundle).
Of course, orb-iiop imports
glassfish-corba-orb, and glassfish-corba-orb knows nothing of orb-iiop
(essential because they are not built
together). The ORB configuration handles this by the iiop-connector
code passing the property
ORBConstants.USER_CONFIGURATOR_PREFIX + PEORBConfigurator.class.getName()
(set to any value)
to the ORB initialization. We set the thread context ClassLoader (which
is used in many places in GlassFish)
in order to make this work, because the ORB will load the ORB
configurator class dynamically based on
stripping the class name from the property.
I certainly am not expecting at this point (remember, I have been
talking about this problem for months now)
to rewrite the ORB initialization to accommodate OSGi. That being said,
it is possible (I think!) to basically
change the ORB init from using Properties to use Map<String,Object>
(possibly with some extensions to
get back the default properties behavior we lose with this change, e.g.
create essentially something
like an ORBProperty<T> class which is basically like a
Map<String,Object> with defaults). I've already
had to create an ORBFactory to create ORB instances in GlassFish,
because OSGi breaks ORB.init() in
the same way we have been discussing here. That makes it possible to
pass the extended properties
to ORBFactory.create. But so far this is not necessary in the ORB
integration work we are doing.
Ken.