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