Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-2604

Issue with multiple REST methods having List<T> arguments



    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.2.5
    • Fix Version/s: None
    • Component/s: Aegis Databinding, JAX-RS
    • Labels:
    • Environment:

      JBoss 4.3 Using CXF 2.2.5


      I have a REST based service method that takes a List<Foo> parameter. The method is annotated with @POST and I can verify that the XML body of the POST request from the server expects the top level element to be <ArrayOfFoo> and a second method that takes a List<Bar> parameter.

      It is important to note that the Foo and Bar classes are in different packages and therefore the namespaces are different.

      The service would look something like this:
      My resource is defined like this:
      public class SomeResource {

      void postFoo(List<Foo> list) {}

      void postBar(List<Bar> list) {}

      When I stop the server in the debugger after posting to "/foo/update" I can see that in the org.apache.cxf.aegis.type.TypeUtil class the getReadTypeStandalone() method is invoked to get the top level type. In this case it will be ArrayOfFoo and the type is located and my method called with the correct list object un-marshalled from XML.

      In the second case, when posting to "/bar/update", ArrayOfBar is not found in the AegisContext and null is returned by the getReadTypeStandalone method.

      The part that really confuses me is that if at runtime (after restarting the server) I invoke the postBar method before invoking the postFoo method, the ArrayOfBar type is located but not the ArrayOfFoo type.

      Some important things to note:
      1. This seems to only affect the ArrayOf<T> classes. Other custom classes from different namespaces are fine.
      2. This only happens when ArrayOfBar is in a different namespace from ArrayOfFoo.


        1. CustomAegisElementProvider.java
          6 kB
          Alan Hazelton



            • Assignee:
              ahazelton Alan Hazelton
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: