trailing block elements must have an id attribute

A couple of weeks back some colleagues working on a POC came across this runtime error when invoking a web service through a generated web service proxy client:

trailing block elements must have an id attribute

This exception was being thrown within the web service proxy client when parsing the response from the web service. Using HttpAnalyzer in JDeveloper (versions 10.1.3.1 & 10.1.3.2 were used) we could see that the request was being sent and a response was being received, so clearly nothing wrong with the web service being invoked. Or so we thought…

It turned out that the published WSDL & XSD and the web service implementation were not matching. The XSD for an element in the response said that Address had a maxOccurs=”1″ however, the web service implementation was returning multiple Address elements. The web service proxy client is generated from the WSDL & XSD so it is only expecting one Address element in the response stream, hence the error at runtime.

We had to double check which was correct, and a quick check through documentation showed that the schema had not been updated when the object model had changed. Once that was determined, it was straight forward to correct the schema entry, maxOccurs=”unbounded”, and regenerate the web service proxy client.

So, if you get this obscure ‘trailing block elements must have an id attribute’ error message at runtime double check that the published interfaces (WSDL & XSD) match the implementation.

ModuleException http:101216 on WebLogic

A number of people have asked about the ‘ModuleException: [HTTP:101216]Servlet:’ error I came across as part of the multi-platform Dice Service example. The experiences are covered in three (first problem, second problem, solved) separate articles which I will collate and summerise here.

Use ant to build web app
Some JEE 5 containers allow you to define your annotated classes and then drop them in an ‘autodeploy’ folder. Not with WebLogic Server v10 though, an ant script is required to do some more work on the web application. Interestingly, the WLS documentation does not refer to autodeploy for web services, in fact according to the WLS Web Service documentation a weblogic ant task ‘JwscTask’ is needed to compile the annotated web service and produce the necessary WAR and EAR for deployment.

Without the JwscTask, simply dropping a JAX-WS web app in the deplopyment folder will give you an deployment error like this:


The deployment error is:
weblogic.application.ModuleException:
[HTTP:101216]Servlet: "DiceServicePort"
failed to preload on startup in Web application:
"WebServices.war".
javax.servlet.ServletException: Servlet class:
'soastation.jaxwsdice.Dice' does not implement
javax.servlet.Servlet

Tell JwscTask the type
Not only is an ant script required to invoke weblogic.wsee.tools.anttasks.JwscTask but when using it with JAX-WS web services you must set the type attribute. The guidelines in the WLS documentation states that the ant tasks need to have a type=”JAXWS” attribute set. Without this, WLS will treat the web service as a JAX-RPC service.







Summary
To deploy JAX-WS web services on WebLogic Server v10 use JwscTask, with type=”JASWS”, in an ant script. Of course, if you are going to the effort of putting an ant script together to build the web application, it might as well have it deploy the web app too.

Dice service working on WLS

As mentioned in a previous post the Dice service, which is my JAX-WS example for a cross platform service implementation, was not working on BEA WebLogic Servier v10. It turns out I missed a key part of JAX-WS & WLS documentation when putting the build script together. The guidelines in the WLS documentation states that the ant tasks need to have a type=”JAXWS” attribute set. Without this, WLS was treating the web service as a JAX-RPC one and that was the cause of the strange WSDL and the runtime exception.

The build-service target now looks like this:







So the only change is setting the type attribute to JAXWS. The WSDL generated for this service is identical to the one generated on Glassfish.

ESBREQUEST in Oracle ESB Routing Services

Oracle’s Enterprise Service Bus (ESB) is designed to implement service-oriented architecture (SOA) and event-driven architecture (EDA), providing a responsive, low-cost, high-impact framework for matching technology needs to business problems.

One of the powerful capabilities of Oracle’s ESB is the ‘Routing Service’ which caters for service virtualization through content based routing. It supports one way and request response operations. One of the challenges with service virtualization and the request response pattern is matching the response from the implementation service to the response that the routing service should return. There is no easy answer to this one, but the Oracle ESB provides some help. One is the transformation capabilities, but you would expect this from any ESB system. The really useful feature is being able to refer to the request in the response transformation. Oracle ESB does this by declaring a parameter to the XSLT called $ESBREQUEST.

Elements in the request can be referred to through XPATH. For example:

This is great, but there are a few things I need to draw to your attention:

  1. $ESBREQUEST refers to the root element of the request sent to the service implementation and not the request sent to the routing service. So, if your implementation service request structure is DoMethodRequest/MyParam then refer to MyParam as $ESBREQUEST/MyParam not $ESBREQUEST/DoMethodRequest/MyParam.
  2. You need to enter the XPATH manually because the mapper does not know the structure of the request.
  3. You have to specify ‘Include Request in the Reply Payload’ when defining the routing rule. This can not be added to the routing rule or XSL file through the tools afterwards.

The latter point is what I really wanted to cover in this article. At the moment, in version 10.1.3, you can not retrospectively ‘Include Request in the Reply Payload’ using the JDeveloper or the ESB console. When you use JDeveloper the first time it puts
in the XSL file and sets attachRequestPayload=”true” in the transformation element of the routingRule section of the routing service esbsvc file.

So, you can do this manually to retrospectively add ‘Include Request in the Reply Payload’ to your existing routing rules. Unfortunately the only way I have found to update the running ESB routing service routing rules with these changes is to to delete the routing service (through ESB console), shutdown JDeveloper, edit the esbsvc file manually, restart JDeveloper and then register the ESB project with the integration server.

The Oracle Mapper tool in JDeveloper which is used to edit XSL files does understand the parameter concept, so you can test your stylesheet in JDeveloper before deploying it. Just open the XSL file in JDeveloper, right click in the design view and select Test. Be sure to enter the ESBREQUEST parameter as an XML fragment. Don’t forget that ESBREQUEST corresponds to the request structure sent to the service implementation and not the request received by the routing service!

This ESBREQUEST parameter gives you the benefit of manipulating the reply such as returning correlation information or using the data from the request to perform filtering and other manipulation that the service implementation does not provide.

Should you wish to use data from the original request received by the routing service then you have to add elements manually to the request transformation. This will work at runtime if the implentation service doesn’t validate the request for extra elements not part of the schema. However, once you add these elements to the XSL transformation you will not be able to use the JDeveloper mapper as it does validate the target document structure against the schema.

More problems with Dice service on WLS

As mentioned before, the Dice service does not auto deploy on WebLogic Server 10. According to the WLS Web Service documentation a weblogic ant task ‘JwscTask’ is needed to compile the annotated web service and produce the necessary WAR and EAR for deployment.

The build script I put together looks like this:

It successfully builds and deploys the web service. The deployed web service endpoint is /Dice/Dice so the service name makes up the context and the servlet url-pattern. As mentioned in a previous post both JBoss and OC4J default the servlet url-pattern to diceserviceport while Glassfish defaults to DiceService.

Also of note is that the WSDL on WLS is so different from the others by using the SOAP array type and ignoring the Die structure in the schema. That means that the size attribute is missing.

The big thing to note though is that there is a runtime error when trying to test the web service:
com.bea.xbean.values.XmlValueOutOfRangeException
at com.bea.xml.soap.SOAPArrayType.
at com.bea.staxb.runtime.internal.LiteralUnmarshalResult.extractSoapArrayType

So the mystery tour continues. I might just try the top down route based on a WSDL from the Dice service deployed on another platform. Naturally, I will keep you posted.