... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)

2006-01-19

BEA WebLogic

I tried again to find an idiomatic way to create web services for BEA that:

  1. can be developed in Eclipse without the use of BEA's workshop
  2. can be built by ANT
  3. favour expression of interfaces in Java over WSDL or XSD
  4. preserve the use of SDO and XmlBeans
  5. use the same classes on the client and server side
  6. allow portions of the SOAP requests or replies to be untyped XML

So far, 1, 2, 3, 4, 5, and 6 seem in reach, but 7 remains elusive. 7 can be achieved by using BEA's proprietary .JWS format, but then some of the other goals are missed (especially 1).

Most of the time today was spent wrestling with, and finally identifying an apparent bug in WLS. See the BEA newsgroup posting:

http://forums.bea.com/bea/thread.jspa?threadID=200079921

Other BEA findings...

As of 9.1, BEA deprecates the use of XMLBeans in Web Services: http://e-docs.bea.com/wls/docs91/notes/new.html.  Does that mean you can't use XMLBeans at all, or just that you shouldn't declare a type as a generic XmlObject?

How do you configure and recover initialization parameters for web services?

Whether generating a service from WSDL (using WSDL2Service) or from Java (using SERVICEGEN), the deployed WSDL does not generate unique SOAPActions for each operation. In fact, they are all blank. As a result, a client is not able to invoke any operation other than the first. Note that even when WSDL2Service is given a WSDL that *does* correctly specify SOAPActions, the deployed service still uses blank actions.

If you write a web service using BEA's proprietary JWS format, then correct SOAPActions are generated.

There are some BEA forum posts about this::

When using SERVICEGEN, make sure that the target EAR file does not exist prior to running the task. Otherwise, the task will update the existing EAR file, and may not actually replace the WebService class. In my case, I had added some methods, but since the class file was not updated, the methods did not appear. I got the error message:

 at weblogic.webservice.server.WebServiceFactory.registerOperation(Lweblogic.management.descriptors.webservice.OperationMBean;Lweblogic.webservice.Port;Lweblogic.webservice.InvocationHandler;Ljava.util.Map;Lweblogic.xml.schema.binding.TypeMapping;Ljava.lang.String;Ljava.util.HashSet;ZV(WebServiceFactory.java:869)

Blog Archive