5 Replies Latest reply on Jul 5, 2004 8:37 PM by cbrettin

    JavaBeans with java.util.Collection properties as parameter/

      I am trying to deploy some SLSBs of an existing app as web services. My central domain object is a tree-like structure where parent nodes keep references to its child nodes in implementations of java.util.Set. For various reasons, changing to typed java arrays or java.util.List is no option.

      I use xdoclet together with the jbossnet subtask to generate the web-service.xml file. I am able to deploy the .wsr file, and JBoss.NET will generate a wsdl file, yet issue a warning:

      [Types] The class java.util.Set is defined in a java or javax package and cannot be converted into an xml schema type. An xml schema anyType will be used to define this class in the wsdl file.

      I cannot, however, use this file to generate a client stub, since some - not all - of those java.util.Set properties are mapped as the type "tns3:Set" where "tns3" is an undeclared namespace. Other java.util.Set properties are mapped as "xsd:anyType" and java.util.List properties as "soapenc:Array". Running wsdl2java against this wsdl file consequently fails with a message to the effect that the type "tns3:Set" is referenced but not declared.

      So why are some sets mapped as "xsd:anyType", others as "tns3:Set"? And what are my options in this situation? I am pretty much new to web services, so any hints are welcome.

      Cheers,
      Olaf

        • 1. Re: JavaBeans with java.util.Collection properties as parame
          james.clover

          Java Collection classes aren't recommended for SOAP interfaces, mostly for interop reasons. If all you're needing is a list of objects without duplicates, then your interface can just be an array of objects. You can treat is as a Set from either side of the interface.

          • 2. Re: JavaBeans with java.util.Collection properties as parame

            Thanks for your prompt answer, James.

            "james.clover" wrote:
            Java Collection classes aren't recommended for SOAP interfaces, mostly for interop reasons. If all you're needing is a list of objects without duplicates, then your interface can just be an array of objects. You can treat is as a Set from either side of the interface.


            I am afraid I cannot change my domain objects to always use arrays instead of Sets. I am using Hibernate as my persistence layer, and Hibernate demands that properties mapped as arrays or Lists strictly obey the list semantics, i.e. be indexed. What's more, it requires a table column holding the index of each array element, and changing the table layout is simply no option.

            On the other hand, I am operating in a homogenous java environment, so interop concerns are a non-issue. So do I have other options?

            Cheers,
            Olaf

            • 3. Re: JavaBeans with java.util.Collection properties as parame
              james.clover

              Sounds like you may want to go talk to the Axis people. The fact that some instances of your Set are being mapped to AnyType (which would be correct) and some are mapped to others seems like a problem in the Axis code generators.

              • 4. Re: JavaBeans with java.util.Collection properties as parame
                rmcdonough

                Hi Olaf,

                Dunno if you've solved your problem or not, but I was faced with a similar problem as I too am using Hibernate for my project. Rather than rearchitect the whole thing, I ended up refactoring my domain object so they each had an interface that could work better in a web service enviroment. This allowed me to have the application work as is, but when I have a webservice call, Jboss.NET will serialize the POJO's interface as opposed to the concrete class. You should know that Hibernate is not aware of any interfaces with my application, only the Web Services deal with those. I hope this is helpful.

                Ryan-

                • 5. Re: JavaBeans with java.util.Collection properties as parame
                  cbrettin

                  SOAP has no standard support for any collection apart from arrays.

                  As prevoius posters have said breaking the SOAP compatibility is generally a bad idea (surely compatibility, not hype, is the reason you are using WS)

                  The varying set serialisation is a bit of a worry, but understandable since (I hope) the first priority for axis is SOAP interop.

                  There are two ways you could bypass the set serialisation problem (or some combinaiton of the two):
                  1) Define a net set of types that use arrays instead of collections, and add methods to your existing types that convert between the two.

                  2) Add custom serialisers & deserialisers to you endpoints - this way you can use arrays "on the wire" but in you code deal only with you collection types

                  3) I know I said two, but that becuase this one is a bad idea - use java's built in XML bean serialiser and add the XML inline or as a soap attachment.