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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com