Marina Vatkina wrote:
Marina
Vatkina wrote:
Ken Cavanaugh wrote:
Sahoo wrote:
Ken Cavanaugh wrote:
Sahoo wrote:
Ken,
It exports javax.activation and javax.transaction packages. In fact, it
has a partial list of those classes.
There are several CORBA system exceptions defined in these two
packages, which were added in
JDK 5. Is there a split package problem here?
yes.
What action would you like to take
about this?
Pl. remove them from those packages and add appropriate Import-Package
statements.
These classes are in the JDK, so I think I just need to remove the
packages.
Marina, was there a need to include the javax.activity and
javax.transaction packages
in glassfish-corba-omgapi for JTS?
Ken, Sahoo,
This was a part of
https://glassfish.dev.java.net/issues/show_bug.cgi?id=5370 and this is
how you Ken explained it last time:
>> I need to change the glassfish-corba-omgapi
>> bundle. It currently includes everything in:
>>
>> javax.activity
>> javax.transaction
>> org.omg.PortableServer.POAPackage (actually the bundle
include org.omg.PortableServer.*)
>>
>> The problem we have is that org.omg.CORBA.TSIdentification is
needed
>> in GlassFish, but is not present in the JDK. However,
everything else
>> in org.omg.CORBA is already in the JDK, and we cannot split
packages.
>
>
There was also an idea to put glassfish-corba-omgapi into
glassfish/lib/endorsed but it didn't work for me when I tried.
And 2 more email from Ken:
#1.
Why does orb bundle have javax.transaction
classes? It should just import them rather than having a private copy.
Not that easy: I use the same ORB code for the JDK and for GF (and I
will go to extreme lengths to preserve this).
There is no place to import the classes from in the JDK.
I think importing these will work.
#2.
Actually, what I should probably do is just
remove the javax.transaction classes from omgapi, and
let felix find them in javaee or javax.transaction or whatever bundle
contains them. I can still build
the ORB with my own version of these classes (which basically never
change anyway), and then
just add an extra dependency in the pom once I get that built.
Now I can rely on these classes being in the JDK, so building is not a
problem, and felix can wire
the dependency at runtime.
You were going on vacation at that time :).
The ORB uses the RMI exceptions defined in javax.activity and
javax.transactions to translate
CORBA system exceptions to RMI exceptions for RMI-IIOP (this is in the
implementation in the delegate
for the standard javax.rmi.CORBA.Util class for the mapSystemException
method).
Looking further into this, the javax.activity classes are in JDK 6 BUT
NOT JDK 5. The ORB has
reflective code that uses these classes, but of course bnd can't find
that. So the easiest fix is:
- Remove the javax.activity and javax.transactions classes from the
glassfish-corba-omgapi bnd file.
- Change
com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException to simply
call the javax.activity classes directly. This will cause bnd to add
the appropriate package to the generated import manifeset entry.
bnd is already generating an import for javax.transactions, so no
change is needed to handle that case.
The only interesting side effect of this is that from now on, it will
NOT be possible to build the ORB
on JDK 6. I don't think anyone cares about that at this point.
With this change, the glassfish-corba-orb bundle imports the following
packages which are not
exported by another glassfish-corba package (not including standard JDK
packages):
- com.sun.jndi.cosnaming (needed for Dynamic RMI-IIOP in order to
implement the JNDI state factory)
- javax.activity
- javax.naming
- javax.naming.spi
- javax.rmi
- javax.rmi.CORBA
- javax.transaction
- org.omg.* (some of this is overridden in glassfish-corba-omgapi)
- org.osgi.framework
- sun.corba (an ARC contract private API essential to the
implementation of the ORB that is provided by all Sun JDK
implementations starting with JDK 5)
The org.omg.CORBA package is an example of exactly what Sahoo was
talking about for the javax packages:
a version is provided in the JDK, but GFv3 needs an extended version
for org.omg.CORBA.TSIdentification,
which is not present in the JDK. glassfish-corba-omgapi includes all
of the classes in org.omg.CORBA to
avoid spit package problems.
I'm running a build and test cycle now, I'll put back this fix after
lunch.
Ken.