persistence@glassfish.java.net

Re: Re1: fixing issue 634?

From: Sherry Shen <Sherry.Shen_at_Sun.COM>
Date: Fri, 06 Oct 2006 14:00:31 -0700

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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>