Re: Re1: fixing issue 634?
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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>