Hi Tom,
Yes, there is a test that sets an Enum value (testCreateCanadian()) and another
one that reads it back and verifies it (testReadCanadian()). I'll ask our SQE
to remove work around and mark the issue 'verified' if the changed test passed.
The SQE suite is executed on each promoted build (after its promotion).
Do you think we need more?
Will the following interop note be sufficient:
* Note also, that ORB fix (when it is available) will need to be applied to all
* prior releases of JDK 5 and JDK 6 and all users of TopLink will need to know
* to use the fix to be able to avoid the problem without this workaround.
If you agree, I'll check it in today (I won't be in on Monday).
thanks,
-marina
Tom Ware wrote:
> Hi Marina,
>
> It looks to me like there is some use of enum in the
> oracle.toplink.essentials.testing.models.cmp3.inherited package. It may
> be just a matter of ensuring the current tests cover the code you are
> changing.
>
> -Tom
>
> Marina Vatkina wrote:
>
>> 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.
>>>>>>>>>>>
>>>>
>>>>
>>>>
>>>>