Details
-
Type:
Bug Fix
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: None
-
Component/s: Development, Version Compatibility
-
Security Level: Public (Public: Anyone can view)
-
Labels:None
-
Similar issues:
KULRICE-6474Try to come up with a better name than "CacheService" KULRICE-2953Rice is currently pulling in the geronimo javamail jar as an undesirable dependency from CXF, this is conflicting with sun javamail functionality KULRICE-13693 Come up with an automated solution for link verification in the Rice portal KULRICE-2634 Implement support for better XML export, XML import and migration features KULRICE-2156When pasting text from a Word document into an EDL text area, XML ends up with garbage in it. KULRICE-4079Add better logging KULRICE-5357update our caching solution for rice. KULRICE-5893 Error messages need to be resolved on the remote services KULRICE-6109 Come up with a way to "auto-generate" documentation on our various configuration parameters KULRICE-805Come up with a method for generating documentation about our XML document structure (XSD schema) -
KAI Review Status:Not Required
-
KTI Review Status:Not Required
Description
Currently, the ImmutableListAdapter is producing XML schema like the following (this example is from the GroupService):
<xs:complexType name="getDirectParentGroupIdsResponse"> <xs:sequence> <xs:element minOccurs="0" name="directParentGroupIds" type="ns1:anyTypeArray"/> </xs:sequence> </xs:complexType>
In this case, anyTypeArray comes from the http://jaxb.dev.java.net/array schema and does not properly use the schema types from the elements of the "array". This is because this adapater is currently declared as follows:
public class ImmutableListAdapter extends XmlAdapter<Object[], List<?>> { ... }
This use of Object[] triggers the issue. Unfortunately, because of the nature of type erasure and the way that the JAXB adapter system works, there is no way to create a single, general-purpose adapter that targets the appropriate parameterized list type.
Possible options here include:
- Look at the possibility introducing a custom CXF interceptor which will translate appropriately, would need to define a custom marker annotation to identify which lists/collections need to be unmodifiable
- Add some functionality to the KSB so that it creates it's own client-side proxies that consider immutability on list return types, would still need a custom annotation as above
- Create an adapter class per immutable parameterized list type and annotate using that
Either way, the current usage of ImmutableListAdapter and ImmutableCollectionAdapter needs to be removed.
Closing since these items are now in the release notes.