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.
Activity
Field | Original Value | New Value |
---|---|---|
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Fix Version/s | 2.0 [ 14190 ] |
Start Date | ||
Fix Date | 2012-01-27 [ set to sprint end date ] |
Status | Resolved [ 5 ] | Closed [ 6 ] |
Workflow | custom [ 97822 ] | Copy of custom for rice [ 212720 ] |
Workflow | Copy of custom for rice [ 212720 ] | custom [ 222468 ] |
Workflow | custom [ 222468 ] | Rice Workflow [ 232216 ] |
Polled the cxf-user mailing list for feedback on how best to handle this.
Thread is here: http://cxf.547215.n5.nabble.com/XmlAdapter-or-CXF-Interceptor-to-enforce-immutability-on-returned-Collections-Lists-td4462231.html