persistence@glassfish.java.net

Re: Re1: fixing issue 634?

From: Sherry Shen <Sherry.Shen_at_Sun.COM>
Date: Fri, 06 Oct 2006 16:27:30 -0700

Hi Marina,

Although issue 193 causes issues 634 and 1266, the fix for
issue 634 removed a complicated workaround in the as9.0ur1
release note, and the remaining issue 1266 has a simple workaround.

Thank you for clarifying the availability of ORB fix for issue 193,
modifying entity-persistence to resolve issue 634, and providing
a simple workaround of issue 1266 in coming as9.1 release.
Your efforts will make it easier for users to use enum in their
applications with entity-persistence.

Sherry


On 10/6/2006 2:02 PM, Marina Vatkina wrote:

> Hi Sherry,
>
> Thank you for testing.
>
> I just closed the new issue 1266 as it's exactly 193 problem that we
> have no control over in persistence code.
>
> thanks,
> -marina
>
> Sherry Shen wrote:
>
>> The fix for issue 634 is verified with the SQE test
>> case on 9.1pe_b20. That is, the enum doesn't cause
>> DescriptorException.
>>
>> The remaining issue is incorrect enum comparison
>> in AppClient in issue 1266.
>>
>> Best Regards,
>>
>> Sherry
>>
>> Tom Ware wrote On 09/29/06 12:59,:
>>
>>> Hi Marina,
>>>
>>> Sounds good.
>>>
>>> -Tom
>>>
>>> Marina Vatkina wrote:
>>>
>>>
>>>
>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>