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