Thanks a lot Ken!
Tom,
If this is the case, we do need to fix the TopLink side - I've seen
people using (they had other questions/problems) our JPA impl with Sun AS 8.x.
We do not want to discourage them, right? I can even add some text about
the interop part of the problem to the comments as well.
thanks,
-marina
Ken Cavanaugh wrote:
> 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.
>>>>>>>
>>>>>>>
>>>>
>>