Hi Tom,
We have an SQE test case that uses the workarounds for this bug. I'm not
sure I can simulate unmarshalling in our unit tests, but I can add Enums
tests (I don't see any in the current list - am I missing them?).
thanks,
-marina
Tom Ware wrote:
> Hi Marina,
>
> It sounds like we do need to make this change. Please add a line about
> the interop issues to your comment as well.
>
> We should ensure the new method is being exercised in our current
> testing and if not we should add a test.
>
> If possible, it would also be nice to add a regression test that
> actually confirms the bug is fixed. I'll let you determine how feasible
> that is.
>
> -Tom
>
> Marina Vatkina wrote:
>
>> 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.
>>>>>>>>>
>>>>>>>>>
>>
>>
>>
>>
>