Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Can't deploy web service in Weblogic with a complex type that contains a sequence of complex types  RSS feed

Jimi Svedenholm
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

We use Weblogic 10.3 in a project I'm working on, and we have a few existing web services that are created by some simple java classes with the javax.jws.WebService annotation. Ie Weblogic generates the wsdl for us.

But now we want to add a new service, where the wsdl is written already, by a third party. So we use wsdl2java to generate some foundation classes, and then we write our implementation class that contains all the logic. But when we try to deploy this webservice in Weblogic it complains with this strange error message:

Unable to deploy EJB: coi-service-list-0.0.1-SNAPSHOT.jar from coi-service-list-0.0.1-SNAPSHOT.jar:

[HTTP:101216]Servlet: "/listOfUpdatedDocuments" failed to preload on startup in Web application: "/coi-service".
java.lang.IllegalStateException: Literal Array item type is not found.
at weblogic.wsee.bind.runtime.internal.LiteralArrayHelper.createLiteralArrayType(
at weblogic.wsee.bind.runtime.internal.Deploytime109MappingHelper.registerType(
at weblogic.wsee.bind.runtime.internal.Deploytime109MappingHelper.registerType(
at weblogic.wsee.bind.runtime.internal.RuntimeBindingsBuilderImpl.createRuntimeBindings(
at weblogic.wsee.deploy.EJBDeployInfo.createWsService(
at weblogic.wsee.deploy.DeployInfo.createWsPort(
at weblogic.wsee.server.servlet.BaseWSServlet.init(
at javax.servlet.GenericServlet.init(

After finding absolutely no documentation whatsoever for this error we tried a few different things, and after some tests we concluded that the problem was that we have a complex type that in turn contains a sequence of complex types. When we as a test tried changing the inner complex type to a string, then the deploy worked.

This is the types-part of our schema:

<xs:schema targetNamespace=""
<xs:complexType name="document">
<xs:element name="documentId" type="xs:string"/>
<xs:element name="documentStatus" type="xs:string"/>
<xs:complexType name="documentArray">
<xs:element name="document" type="tns:document" minOccurs="0" maxOccurs="unbounded"/>

As I mentioned before, the wsdl is provided, and we can't modify it. So we need to make Weblogic be able to handle it as it is.

Then as a small test, we tried skipping the wsdl temporarilly, and deploy the ejb with just the java code. Then, to our surprice, the deployment worked like a charm, and the web service worked when we tried it using the built in test client in Weblogic. And when we look at the generated wsdl it looks pretty much identical to the original wsdl. So how come Weblogic couldn't handle the original wsdl, but can handle the java-code and then generate a wsdl that is practically the same as the one that it couldn't handle in the first place?

My guess is that when Weblogic starts with the java classes, it automatically knows what java class each complex type should be mapped to, something that it doesn't know when it starts with the wsdl. What we really would want is to be able to provide the wsdl for Weblogic, and make it use the mappings defined as XmlType annotations in the java classes. Can that be done? If not, how can we make Weblogic understand that we want it to use our java classes for specific complex types? Oh, and one more thing, I think we must restrict our web service to JAX-RPC 1.1.

  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!