7 Replies Latest reply on Jul 12, 2011 4:33 PM by Mario Antollini

    JAXB Transformation Quickstart

    Mario Antollini Newbie

      Hello,

       

      I have just implemented a JAXB quickstart following Tom Fennelly's screencast.

       

      I have it working now (using SOAP binding) but I wanted to discuss some things before pushing the code.

       

      1 - My biggest concern is that, when using JAXB, I had to modify both the signature of the operations and, thus, the internal implementation of the service.

       

      In concrete, before using JAXB the Service looked like this:

       

      @Service(OrderService.class)
      public class OrderServiceBean implements OrderService {
          
          @Override
          public OrderAck submitOrder(Order order) {
              // Create an order ack
              return new OrderAck()
                  .setOrderId(order.getOrderId())
                  .setAccepted(true)
                  .setStatus("Order Accepted");
          }
      
      }
      

       

      Now, with JAXB, it looks like this:

       

       

      @Service(OrderService.class)
      public class OrderServiceBean implements OrderService {
          
          @Override
          public SubmitOrderResponseType submitOrder(SubmitOrderType order) {
              // Create an order ack
              OrderAckType orderAck = new OrderAckType();
              orderAck.setOrderId(order.getOrder().getOrderId());
              orderAck.setAccepted(true);
              orderAck.setStatus("Order Accepted");
              SubmitOrderResponseType sort = new SubmitOrderResponseType();
              sort.setOrderAck(orderAck);
              return sort;
          }
      
      }
      

       

      Am I doing something wrong or is it intended to work this way? I am asking cause I think JAXB is being too invasive here. If the databinding of a running service needs to be changed in the future, the signature will need to change as well.

       

      2 - One minor issue was that during the execution of wsconsume.bat, the source files were generated OK, but the compilation failed with this error: 

       

      .\org\switchyard\quickstarts\transform\jaxb\OrderService_Service.java:60: cannot find symbol
      symbol  : constructor Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
      location: class javax.xml.ws.Service
              super(WSDL_LOCATION, SERVICE, features);
              ^
      .\org\switchyard\quickstarts\transform\jaxb\OrderService_Service.java:67: cannot find symbol
      symbol  : constructor Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
      location: class javax.xml.ws.Service
              super(wsdlLocation, SERVICE, features);
              ^
      .\org\switchyard\quickstarts\transform\jaxb\OrderService_Service.java:74: cannot find symbol
      symbol  : constructor Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
      location: class javax.xml.ws.Service
              super(wsdlLocation, serviceName, features);
              ^
      3 errors
      Failed to invoke WSDLToJava
      org.apache.cxf.tools.common.ToolException: Failed to compile generated code
              at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:115)
              at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:262)
              at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:138)
      
      

       

      The source files compiled ok when integrated in my project.

       

      3 - A minor bug showed up in Windows. In wsconsume.bat, there is a "\" at the end of line 22 which should be replaced by "/" (otherwise it fails to run). I do not know whether this belongs to Switchyard's or AS7's team.

       

      Any thoughts?

       

      Thanks,

      Mario

        • 1. Re: JAXB Transformation Quickstart
          Keith Babo Master

          Hey Mario,

           

          Thanks for blazing the trail here.  Can you post a link to your quickstart branch which contains the new quickstart?  That will help sort some of this out.

           

          One of the issues I think you are probably running into here is that the existing Orders quickstart uses a WSDL that we created from scratch vs. using web service generation tooling.  This means that the default naming for objects and XML types will not match what we have in the quickstart, hence the requirement to change the interface definition.  If you're going to use the orders quickstart as the basis for your JAXB quickstart, then you should be able to annotate the existing Order and OrderAck objects with JAXB annotations and not mess around with any of the generation tooling.  On the other hand, if you want to start from scratch, then you could take a WSDL, generate the appropriate objects, then use those in your service interface.

           

          cheers,

          keith

          • 2. Re: JAXB Transformation Quickstart
            Mario Antollini Newbie

            Hey Keith,

             

            this is my topic branch: https://github.com/antollinim/quickstarts/tree/SWITCHYARD-333

             

            So, are you saying that names for the generated classes are taken from the WSDL?  For example, the submitOrder parameter type was called "SubmitOrderType" instad of "Order" in the WSDL? That makes sense...

             

            I will try that then.

             

            Thanks for your help!

            Mario

            • 3. Re: JAXB Transformation Quickstart
              Tom Fennelly Master

              Hey Mario.

               

              Maybe I'm looking at this wrong, but when I think of JAXB I don't really think in terms of taking something that was hand crafted earlier and is already working and then trying to impose JAXB on top of it.  Sure you can take existing Java classes and annotate them with JAXB annotations (manually cross ref between the java types and the xsds.... adding JAXB annotations appropriately) but that seems like it would be a total pain to get working.  I know when I tried this in the past it drove me insane.

               

              When I think JAXB I think of taking an already defined xml schema (or wsdl) and generating a set of annotated POJOs from it and then building your service... not the other way around.  Maybe I shouldn't have based that screencast on the existing orders demo wsdl and operations.

               

              T.

              • 4. Re: JAXB Transformation Quickstart
                Keith Babo Master

                 

                Maybe I'm looking at this wrong, but when I think of JAXB I don't really think in terms of taking something that was hand crafted earlier and is already working and then trying to impose JAXB on top of it.  Sure you can take existing Java classes and annotate them with JAXB annotations (manually cross ref between the java types and the xsds.... adding JAXB annotations appropriately) but that seems like it would be a total pain to get working.  I know when I tried this in the past it drove me insane.

                 

                I agree that there is a definite YMMV element to this, but it's still an important use case that we should make sure works.  If you have a set of domain objects and you plan to have an XML representation of those objects, adding JAXB annotations seems like a reasonable way to do that.  You can then generate a schema for those objects and that can be referenced from any WSDLs that you create.

                • 5. Re: JAXB Transformation Quickstart
                  Tom Fennelly Master

                  Keith Babo wrote:

                   

                  I agree that there is a definite YMMV element to this, but it's still an important use case that we should make sure works.  If you have a set of domain objects and you plan to have an XML representation of those objects, adding JAXB annotations seems like a reasonable way to do that.  You can then generate a schema for those objects and that can be referenced from any WSDLs that you create.

                   

                  I agree it should be totally possible and I've no reason to think it's not, so long as you manage to apply the annotations properly.  That's the trick imo - anything more than a trivial model would be a tedious, error prone head wrecker

                   

                  Anyway... just trying to highlight where the possible frustrations for Mario may be coming from.

                  • 6. Re: JAXB Transformation Quickstart
                    Mario Antollini Newbie

                    Thanks Tom,

                     

                     

                    Tom Fennelly wrote:

                     

                    Hey Mario.

                     

                    Maybe I'm looking at this wrong, but when I think of JAXB I don't really think in terms of taking something that was hand crafted earlier and is already working and then trying to impose JAXB on top of it.  Sure you can take existing Java classes and annotate them with JAXB annotations (manually cross ref between the java types and the xsds.... adding JAXB annotations appropriately) but that seems like it would be a total pain to get working.  I know when I tried this in the past it drove me insane.

                     

                    When I think JAXB I think of taking an already defined xml schema (or wsdl) and generating a set of annotated POJOs from it and then building your service... not the other way around.  Maybe I shouldn't have based that screencast on the existing orders demo wsdl and operations.

                     

                    T.

                     

                    you are right, that was my first misconception. I was expecting JAXB to magically do the data binding for an existing Service.

                     

                    Mario

                    • 7. Re: JAXB Transformation Quickstart
                      Mario Antollini Newbie

                      Hi Keith,

                       

                       

                      Keith Babo wrote:

                       

                      Hey Mario,

                       

                      Thanks for blazing the trail here.  Can you post a link to your quickstart branch which contains the new quickstart?  That will help sort some of this out.

                       

                      One of the issues I think you are probably running into here is that the existing Orders quickstart uses a WSDL that we created from scratch vs. using web service generation tooling.  This means that the default naming for objects and XML types will not match what we have in the quickstart, hence the requirement to change the interface definition.  If you're going to use the orders quickstart as the basis for your JAXB quickstart, then you should be able to annotate the existing Order and OrderAck objects with JAXB annotations and not mess around with any of the generation tooling.  On the other hand, if you want to start from scratch, then you could take a WSDL, generate the appropriate objects, then use those in your service interface.

                       

                      cheers,

                      keith

                       

                      I updated the WSDL to have the names I was expecting. The operation signatures remain the same now. However the internal implementation still depends on JAXB's bindings. I guess this is expected, right?

                       

                      I pushed the new version in the same topic branch: https://github.com/antollinim/quickstarts/commits/SWITCHYARD-333

                       

                      Does it look better now?

                       

                      Mario