persistence@glassfish.java.net

Re: Re1: fixing issue 634?

From: Ken Cavanaugh <Ken.Cavanaugh_at_Sun.COM>
Date: Thu, 28 Sep 2006 16:23:28 -0700

On Thu, 2006-09-28 at 13:40 -0700, Marina Vatkina wrote:

> Ken,
>
> Will this change depend on the JDK version?


That depends. First, we clearly need to fix this in the app server ORB.
Both the sending ORB and
the receiving ORB will need to change. If the sender and the receiver
are both using the app
server ORB, that is all that is needed. However, standalone clients
that are NOT using
appserv-rt.jar would need to use an ORB with the issue fixed in order to
operate correctly.
So, for example, a pure standalone client on JDK 5u8 would NOT correctly
marshal or unmarshal
enums from a fixed app server ORB. We would need to patch the JDK ORB
in a JDK 5 (and 6)
update release.

This says nothing about interoperation with other ORBs, if people are
using RMI-IIOP from a non-Sun
ORB. This may or may not be a problem: a lot of customers just use a
third party ORB for pure IDL,
not RMI-IIOP.

There are potentially a lot of ORBs that need to implement the change
(whatever it ends up being).
We would need to patch at least JDK 5, JDK 6, AS 9, and AS 9.1. AS 8 is
a problem: the fix will force
the ORB to require at least JDK 5, but AS 8.x still runs on JDK 1.4.2
(although probably most customers
are running on JDK 5 by now). I can probably construct a patch that
uses reflection to find java.lang.Enum
as needed, that would not handle enums on JDK 1.4.2.

Interop is the biggest challenge in fixing this problem.

Ken.

>
> thanks,
> -marina
>
> Ken Cavanaugh wrote:
> > On Thu, 2006-09-28 at 15:04 -0400, Tom Ware wrote:
> >
> >>Hi Marina,
> >>
> >> I am waiting for Ken's response about the question you posed in your
> >>earlier email:
> >>
> >>"When would such fix make it into GF? Best case? Worst case?"
> >>
> >
> > The discussion on the JavaIDL RTF is active now, and as usual there are
> > conflicting goals
> > to consider. I'd say best case is AS 9.1 M4 (M3 is a slight possibility
> > IF the RTF solution
> > is arrived at quickly, and it not too hard to implement), worst case is
> > AS 9.2.
> >
> > Ken.
> >
> >>
> >>-Tom
> >>
> >>Marina Vatkina wrote:
> >>
> >>>Tom,
> >>>
> >>>Any decision on this? ORB bug might not be fixed in 9.1 time frame.
> >>>
> >>>-marina
> >>>
> >>>Marina Vatkina wrote:
> >>>
> >>>
> >>>>Tom,
> >>>>
> >>>>I added all that I could to the comments:
> >>>>
> >>>>diff -r1.3 EnumTypeConverter.java
> >>>>107a108,136
> >>>>
> >>>>
> >>>>
> >>>>> /**
> >>>>> * INTERNAL:
> >>>>> * Convert Enum object to the data value.
> >>>>> *
> >>>>> * Because of the following ORB issue, the Enum object returned from a
> >>>>> * client via unmarshalling, does not compare equals() to the instance
> >>>>> * created in this VM. This results in a corresponding value not being
> >>>>> * found, and in unexpected exception "No conversion value provided for
> >>>>> * the attribute [XXXXX]".
> >>>>> * The solution is to return the corresponding value from the Enum instance
> >>>>> * directly.
> >>>>> * Note, that this problem doesn't affect data to object conversion.
> >>>>> *
> >>>>> * The ORB issue: JDK 5 support for enum also required a small addition to
> >>>>> * the Java serialization spec to accommodate enums. This requires a
> >>>>> * corresponding change in the RMI-IIOP specification, which has a different
> >>>>> * serialization format than Java serialization and standard RMI over JRMP
> >>>>> * (not RMI-IIOP).
> >>>>> */
> >>>>> public Object convertObjectValueToDataValue(Object attributeValue, Session
> >>>>>
> >>>>>
> >>>>session) {
> >>>>
> >>>>
> >>>>
> >>>>> if (attributeValue == null) {
> >>>>> return super.convertObjectValueToDataValue(null, session);
> >>>>> }
> >>>>>
> >>>>> Enum theEnum = Enum.class.cast(attributeValue);
> >>>>> return (m_usesOrdinalValues)? theEnum.ordinal() : theEnum.name();
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>Is it enough?
> >>>>
> >>>>thanks,
> >>>>-marina
> >>>>
> >>>>Ken Cavanaugh wrote On 09/27/06 14:01,:
> >>>>
> >>>>
> >>>>
> >>>>>On Wed, 2006-09-27 at 13:05 -0700, Marina Vatkina wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Hi Tom,
> >>>>>>
> >>>>>>Unfortunately, the ORB bug can't be fixed as per OMG spec it's the correct
> >>>>>>behavior. This is what Ken Cavanaugh wrote in the 193 notes: "Can't fix
> >>>>>>this for AS 9. May need a spec change at the OMG level."
> >>>>>>
> >>>>>>We had several user that needed ugly work arounds because of that problem.
> >>>>>>
> >>>>>>Ken, can you please comment on that? (Don't worry if you are not on the
> >>>>>>alias - I'll accept your email).
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>The problem is that JDK 5 support for enum also required a small
> >>>>>addition to the Java serialization
> >>>>>spec to accommodate enums. This requires a corresponding change in the
> >>>>>RMI-IIOP specification,
> >>>>>which has a different serialization format than Java serialization and
> >>>>>standard RMI over JRMP
> >>>>>(not RMI-IIOP). There is now an issue at the OMG (issue 10336: see
> >>>>>http://www.omg.org/issues/java2idl-rtf.open.html#Issue10336 ), but the
> >>>>>Java to IDL RTF has not
> >>>>>yet voted on this.
> >>>>>
> >>>>>I think a reasonable approach for us might be to implement the
> >>>>>resolution to the issue as soon as
> >>>>>it is finalized and voted in. I think this will have to wait until the
> >>>>>JavaIDL RTF is re-chartered in
> >>>>>Anaheim this week. Harold used to be the Sun rep on the RTF, but since
> >>>>>he's moved on to
> >>>>>WSIT, I'll be taking his place on the RTF.
> >>>>>
> >>>>>I've just sent an email to the RTF alias to see when we can get started
> >>>>>on the issue. I'll also need to investigate
> >>>>>the impact of this fix on interoperability with other ORBs (especially
> >>>>>ours) that do not have the
> >>>>>fix.
> >>>>>
> >>>>>Ken.
> >>>>>
> >>>>>
> >>
>