Chris Hogue's Blog

Chris Hogue's Homepage
Chris Hogue is a Senior Engineering Program Manager on the Eclipse Tools team. After spending several years working on Workshop features for JEE applications he now focuses on the developer tools for WebLogic Event Server. Chris has been with BEA for a cumulative 6 years during which time he held several different positions on the WebLogic Portal and Workshop teams.

Event Server Developer Tools 2.1

As Robin wrote yesterday we've released a new version of the Event Server developer tools. This is an exciting release in that it brings the tools up to the latest version of Eclipse and also introduces the first part of the visual design tools planned for Event Server applications.

Being on the latest release of Eclipse has its obvious benefits. For more information on the system requirements and installation instructions visit the update site.

The main feature in this release is the EPN Viewer.

The EPN Viewer shows the overall flow of an Event Processing Network (EPN). Because Event Server applications are so flow oriented it can sometimes be hard to discern that flow just by looking at the EPN Assembly file. This view gives the natural view the application deserves.

But more than just for orientation the viewer serves as a central jumping-off and navigation point for the project. From the viewer you can jump to the source artifacts that define the nodes in the network. To go to the EPL rules for a processor simply select the Go to Configuration Source menu item. The config file containing that processor and its rules will open right up.

To go to the Java source file defining a POJO simply select the Go to Java Source menu item and that Java file will be opened.

You can see that all nodes also allow you to jump to their definition in the EPN Assembly source file. Of course you have options to print the network or export it to an image file for documentation purposes.

While the viewer is currently focused on visualization and navigation there's a lot more to come. In the coming releases you'll be able to edit the network directly on the viewer in a drag and drop style. And there are other features in the works all designed to make building and testing event server applications easier than ever.

For an overview of building Event Server application with these developers tools take a look at the updated screencast. And let us know what you think.

Event Server Development Environment for Eclipse 2.0.1 Now Available

Users who already have the 2.0 GA tools can simply go to the Eclipse Update Manager to get the latest version (Help > Software Updates > Find and Install... > Search for updates of currently installed features). This assumes you've still got the Event Server update site registered in your update manager.

No other migration steps are necessary such as upgrade projects or servers. The tools will run fine on existing GA workspaces.

For those users who don't already have the tools, download and installation instructions are on the update site:

http://dev2devclub.bea.com/updates/wlevs-tools/2.0/

A special note for anyone still using the Tech Preview tools, be sure to see the installation notes on the installation instructions page. There are a couple of steps necessary to upgrade a workspace from that release to either 2.0 GA or 2.0.1.

WebLogic Event Server 2.0 Development Environment for Eclipse Now GA

WebLogic Event Server 2.0 Development Environment for Eclipse Now GA!

Formerly released as a Technology Preview, the Event Server Development Environment for Eclipse ("Event Server Tools") are now supported and generally available.

This release of the tools contains improvements to the Technology Preview features as well as additional features not available in that release. Highlights of the 2.0 release include:

• Simple Event Server project setup
• Event Server startup/shutdown/deployment control from within the IDE
• Editors for Java and XML artifacts that comprise an Event Server application
• EPL Syntax Highlighting
• Integrated "One Button" debugging
• Application Export wizard for distributing the built application to other environments

For download and installation instructions please visit the Event Server Tools Update Site.

** Tech Preview Users **

Those already using the Tech Preview tools should be careful to read the installation notes on the update site linked above. While the tools can be installed over the existing Tech Preview installation, projects and server definitions must be recreated or some features will not work.

Workshop 10.1 Ships!

Workshop 10.1 Ships

We're happy to be able to announce that the release many of you have been asking for is now available. Carrying the 10.1 version number, this release is the true convergence of the Workshop for WebLogic and Workshop Studio product lines. No longer are there two separate IDEs, two separate product lines. They are now one and the same, though there are still a few different packages from which to choose.

Highlights

Think of this release as merging the features of each product with the features of the other. Traditional Workshop for WebLogic users gain all of the advanced tools provided by Workshop Studio such as WYSIWYG JSP/JSF tools, ORM tools including JPA and Hibernate, relational database tools, and of course all the advanced navigation, visualization, and validation that comes with AppXray.

Oh yeah, and the Page Flow tools have been integrated with AppXray, so you'll find all the source level features you'd expect including completion, validation, and navigation that is fully Page Flow aware.

Traditional Workshop Studio customers gain all of the enterprise level tools provided in Workshop for WebLogic including advanced Web Services, EJBGen, and Apache Beehive tools.

Also new to Workshop for WebLogic customers is support for developing against multiple versions of WebLogic Server. While the previous 10.0 IDE was tied to the 10.0 version of the server, the 10.1 IDE allows you to choose whether you want to develop and deploy against WLS 9.2 or WLS 10.0. So for those that are on 9.2 and can't upgrade their servers just yet, you still reap all the benefits of the new tools. And of course it has wizards to make it easy for you to move up to 10.0 when you're ready.

The Packages

10.1 comes in three packages--Workshop for WebLogic, Workshop Studio, and Workshop for JSP. The differences are:

Where to Get It

Things You Should Know

A few things to know regarding Workshop 10.1:

Platform Products:

This release is aimed at support for WLS, and therefore does not include WLP or WLI. Each of these products will be picking up the features in this IDE in one of their coming releases.

Multiple WLS Version Support:

A subset of the features are available on pre-9.2 versions of the server. Annotated Web Services, EJBGen, and Beehive are not available on pre-9.2 servers. The 8.1 server support does not include Workshop 8.1 runtime support, and JPA will require 9.0 and up. Project Facets will constrain all of this for you so that you don't get into a configuration that won't work. Just be sure to pick the right target runtime on the first page of the project wizards.

Have a look and let us know what you think!

J2EE Libraries, Workshop, and You

With the 9.0 release WLS introduced a new feature called Shared J2EE Libraries--sometimes also called J2EE Libraries, or Library Modules. J2EE Libraries are typically fully valid J2EE modules that are simply deployed with a flag to indicate it's a library. See the link for details on what they are.

Why would you care? If you're using Workshop for WebLogic, then a lot of the maintenance of your project is dramatically eased by the use of J2EE Libraries. Instead of dropping a collection of jars such as Struts and it's dependencies in the WEB-INF/lib folder, you just reference the Struts J2EE library and it's all taken care of for you. And if you're using a layered product like WLP or WLI then you're using even more as these products make extensive use of J2EE Libraries.

This post presents a quick list of the top 3 things you should know about J2EE Libraries and how they work in the IDE.

List of Available J2EE Libraries

You can find the list of pre-loaded J2EE Libraries through the Window > Preferences > WebLogic > J2EE Libraries page. By default the libraries that BEA products ship will be shown here. Notice that you can also add your own libraries to the list--a prerequisite to using them in a project.

Adding a Reference to a J2EE Library

Actually you can do this a couple of ways. The easiest is to select the right facets when creating a project. Facets will do all the setup of the libraries for you. For example, if you create a Dynamic Web Project and select the Struts facet, you'll get a project that looks something like this.

Notice that it shows a reference to the struts-1.2 library. The node under the Java Resources > Libraries tree is called a classpath container and is the bit that makes the classes in that library available on your build-time classpath.

You'll also notice a listing of the J2EE Libraries in the WebLogic Deployment Descriptor (i.e. weblogic.xml). This is the reference that makes it available to your application at runtime.

References can also be added after project creation and without the use of facets. Because there are a couple of places to modify to add the reference, rather than trying to add them in all the right places simply open the Project Explorer. On the WebLogic Deployment Descriptor > J2EE Libraries node, select Add... When you add a library reference from here the IDE will do all the setup for you.

Auto-Deployment

When you have J2EE Library references on a project, the IDE will help you deploy them to your development server. If your domain does not already have the required library deployed, the IDE will deploy it for you automatically. So if you add Struts for example, and are developing against a plain WLS domain that doesn't already have the library deployed, it will automatically be deployed for you when you publish your project.

Awareness of this feature is important because when you go to deploy your project to another server you will have to make sure the right libraries are deployed on that server.

I hope this information is helpful--more on J2EE Libraries later...

Keeping the Workspace Light

Going against the defaults of a piece of software can be a frustrating experience. We've all spent our fair share of time messing around in the settings and preferences getting it just the way we like it. Then inevitably we end up re-installing the software, losing the settings, or just want it to work the exact same way across the 4 computers we use. In a lot of ways it makes sense to stick with the defaults whenever possible.

Well, the default Eclipse workspace model isn't one of them :)

When you initially create a project in Eclipse it will try to put the project artifacts directly into the workspace. The trouble is the projects most people work on are stored in an SCM system. And for me, I'd prefer to keep my local SCM directories free of my individual IDE settings and temporary working areas the IDE uses. There are also times I just want to start with a fresh workspace, perhaps including existing projects from another workspace.

Because of that I encourage people to place their projects outside of the workspace. It's not hard to do, you just have to tell it where to put the files during project creation:

As a corollary to this, a lot of people don't actually create the projects they work on. In fact, if you have 5 people working on a project, only one of them created it. The other 4 checked it out of SCM and have to get it into their IDE somehow. Again, this is simple to do while still keeping the workspace directory separate from the projects. Just use the File > Import... > Existing Projects into Workspace.

But don't let that name fool you--it doesn't mean you have to physically copy them into your workspace. Sticking with the theme of keeping the workspace separate from the projects, make sure to leave the "Copy projects into workspace" checkbox unchecked.

And in case you've not run across it yet, workspaces themselves are inherently tied to a machine and therefore not intended to be shared. They contain many settings, some of which are absolute paths to locations on the local disk. So share the projects, but keep workspaces individual.

Until next time...

Annotation Overrides in a Cluster

At the end I set out a section of things to watch out for, but there's another step to be aware of when deploying these to a cluster. Because the console is sitting on the admin server, a couple of the J2EE Libraries have to be targeted to the admin server of the cluster for it to be able to recognize the annotation manifest. Specifically, you'll need to target the weblogic-controls-1.0 and beehive-netui-1.0 J2EE Libraries. Without doing this you will see the same error described in the earlier post:

"javax.enterprise.deploy.model.exceptions.DDBeanCreateException: [J2EE Deployment SPI:260142]The descriptor at 'META-INF/annotation-manifest.xml' in module 'ServicesWeb.war' is not recognized, and could not be parsed."

You shouldn't need to (and normally wouldn't want to ) target the whole application to the admin server. Let us know how it goes...

Testing a Service Control

A while ago I described how to easily test controls in the Workshop IDE. Since then there's been no shortage of people asking how to test controls that rely on a J2EE container. It usually comes in the form of the question "How do I test a service control?"

There are several approaches you can take to this problem. One way would be to front it with a web service, page flow, or servlet and use the existing JUnit extensions for these technologies. Another option, and the one I'll describe here, is to use Cactus.

The good news is that WTP (and thus Workshop) comes with built-in Cactus integration. This allows you to run ServletTestCases right in the IDE along with your other tests and get the results in the JUnit results view, etc. But there are a couple of tricks you'll need to know to use it with a service control.

For a tutorial on the basic WTP and Cactus integration (which I won't re-hash here) see this article on the WTP website. Beware that the article is a little dated. In particular you don't need to manually add the jars to the build path, just dropping them in WEB-INF/lib will take care of that for you.

The first trick to know about is that you need to change the JRE on your project to point to the Sun VM instead of JRockit. This is because Cactus actually has an invalid attribute in one of its class files that the Sun VM doesn't try to validate, but JRockit (correctly) does. This will manifest itself as a ClassFormatError similar to:

java.lang.ClassFormatError: org.apache.cactus.internal.configuration.ConfigurationInitializer

I'm told that JRockit may have a "fix" for this in a future release, but for now the easiest way to get around this is to use the Sun VM for Cactus tests. I believe it's just an issue with how it was compiled--not a source issue. If you want to continue using JRockit for the tests you may also be able to recompile the Cactus source, but that's an exercise left for the reader.

You can change the JRE by right-clicking the JRE System Library container on the project, selecting Configure, and selecting "jdk150_06".

The next step is to make your TestCase class. You've got two options here. You can subclass ServletTestClass and instantiate the service control programmatically. An example of that might look like:

@ControlReferences({TestServiceControl.class})
public class SimpleTestCase extends ServletTestCase {

  public void testServiceControl() throws ClassNotFoundException {
    TestServiceControl myControl = (TestServiceControl) Controls.instantiate(
          getClass().getClassLoader(), "controls.TestServiceControlBean", null);
		
    String string = myControl.saySomething("hi");
    assertEquals("say hi",string);
  }
}

Notice that this snippet uses a @ControlReferences annotation. This is necessary because the service control uses assembly, and @Control and @ControlReferences are the two annotations that trigger assembly. Since this snippet instantiates the control programmatically and thus does not use @Control, without @ControlReferences it won't have the artifacts it needs at runtime and will fail.

The other option is to subclass ControlTestCase as described in my earlier post and wrap it with Cactus' ServletTestSuite. This approach is my preferred approach since you get all the benefits of the declarative instantiation and injection. And it's just cleaner. Note that this approach no longer requires the @ControlReferences annotation.

public class ControlTestCaseCactusWrapper 
    extends ControlTestCase {
	
  @Control
  TestServiceControl testServiceControl;
	
  public void testControl() {
    String string = testServiceControl.saySomething("hi");
    assertEquals("say hi",string);
  }
	
  public static Test suite()
  {
    ServletTestSuite suite = new ServletTestSuite();
    suite.addTestSuite(ControlTestCaseCactusWrapper.class);
    return suite;
  }	
}

If you try to run your test with Run on Server now you'll probably see an error like:

java.lang.NoClassDefFoundError: weblogic/logging/LogEntry

What's happening is that Cactus is going through commons-logging, and Workshop installs a nice bridge that integrates commons-logging with the WebLogic logging infrastructure. In this case that logging infrastructure doesn't end up on the classpath (because of some quirkiness around how Cactus works). Again, you've got two options. One is to put weblogic.jar onto the project classpath. You can do this by going to Windows > Preferences > Server > Installed Runtimes > BEA WebLogic v9.2. On this screen is an option to put weblogic.jar on the classpath instead of wls-api.jar.

Normally we really don't recommend this because it can slow down your IDE (lots more classes to sift through) and because it makes it easier to take dependencies on non-API classes. So be careful to stay within the documented API if you take this approach.

The alternative is to disable the logging bridge for your tests. This is done by modifying the commons-logging.properties file in your project (usually in WebContent/WEB-INF/classes or EarContent/APP-INF/classes). Just comment out the line or change it to point to a different LogFactory so it will no longer look for the WLS classes. You probably want to do this only for your tests; make sure this bridge is still enabled when you're deploying and running your application.

And that should be it. At this point you should be able to right-click your test case and select Run on Server (make sure you choose this instead of Run As JUnit Test) and get the integration with the IDE's JUnit view, etc.

Effectively Managing Workshop Extensions

It's no secret that one of the benefits of using Eclipse is what it provides in extensibility. But there are good ways and bad ways to manage that extensibility.

Now that the Eclipse-based Workshop has been out for a while it's become clear that people don't just stick with the Workshop plug-ins we give them (not that this is at all surprising). They add all sorts of third-party plug-ins from SCM plugins, Spring plugins, to all sorts of plugins for products I've never heard of :)

While Eclipse does allow you to just drop all those plug-ins in the main eclipse directory, doing so will make it harder to manage, particularly when you want to move to a newer or different version of Eclipse (or Workshop) itself. You'll have to physically move all the plugins over with it.

A better way to manage your extensions is to use Eclipse's extension location mechanism. This is a very simple mechanism that allows you to put your third-party plugins in a separate directory and link to them from the main Eclipse install. This way when you want to drop in a new Eclipse, you don't have to move all the other plugins. Just link the new Eclipse to the existing extension locations.

To manage the list of extension locations go to the Help > Software Updates > Manage Configuration page. If you do this with Workshop you'll see on the screen that pops up a whole list of extension locations. That's because this is exactly how Workshop adds its plugins to the base Eclipse.

But it's not just for BEA plugins. You can add your own extension locations to this list. In fact this is generally the recommended way of adding plug-ins.

Processing mustUnderstand Headers with the ServiceControl

Meta-information about web service messages is often transmitted in the header of the message (within the SOAP envelope, not in the transport headers). These are typically used for information such as user credentials, callback endpoint addresses, etc. Services that send these messages can flag each header with a mustUnderstand attribute that indicates that they require the receiver of the message to understand that header. If the receiver doesn't understand that header, the message fails.

In the world of the ServiceControl and JAX-RPC in general, the client stack will typically throw an exception if it encounters a mustUnderstand header that hasn't been processed. It's up to the client to process that header on the incoming message before the underlying stack checks it.

The way this is done is with a handler. The handler runs before the underlying JAX-RPC stub processes the message. Handlers are supposed to take whatever the appropriate action is for that header, then either remove the mustUnderstand attribute from the header or change its value to false. It takes a bit of code, but nothing special.

For information on how to add a handler to a ServiceControl, see my earlier post on the subject.

The question now is what the handler actually looks like. Here it is:

public class ClientHandler extends GenericHandler {

	...

  @Override
  public boolean handleResponse(MessageContext context) {
    return setUnderstoodHeader(context,"http://services","SomeHeader");
  }
	
  private boolean setUnderstoodHeader(MessageContext context, String namespace, String local) {
    SOAPMessageContext smc = (SOAPMessageContext)context;
    SOAPMessage msg = smc.getMessage();
    SOAPPart sp = msg.getSOAPPart();
    try {
      SOAPEnvelope se = sp.getEnvelope();
      SOAPHeader sh = se.getHeader();
      Iterator iterator = sh.examineAllHeaderElements();
      while (iterator.hasNext()) {
        SOAPHeaderElement el = (SOAPHeaderElement) iterator.next();
        if(namespace.equals(el.getNamespaceURI()) &&
                       local.equals(el.getLocalName())) 
        {
          
          // Do processing of the header information here
		  
          el.setMustUnderstand(false);
          return true;
        }
      }
    } catch (SOAPException e) {
      e.printStackTrace();
    }
	return false;
  }
}

It looks like a lot of code but it's not as scary as it looks. Most of the code here is boiler plate code for iterating through the SAAJ DOM to grab the header. First, the handleResponse method is called on the handler. This is the callback API that the JAX-RPC plumbing calls.

Next there's a method for setting a particular header's mustUnderstand attribute as understood. It simply looks through the DOM to get the header section. Then it looks through the headers for the one specified by the namespace and local name sent to the method.

Finally it does whatever processing is appropriate for the header, then sets mustUnderstand to 'false' to indicate that it has processed the header. Alternatively, you could remove the mustUnderstand attribute by calling el.removeAttributeNS(...) rather than setting the value to false.

Once this call is complete the underlying JAX-RPC infrastructure will continue processing the message, ultimately making the message available to the ServiceControl (or JAX-RPC stub) client.

Workshop 9.2 Maintenance Pack 1 Available

The download can be found here:

http://commerce.bea.com/products/weblogicplatform/weblogic_prod_fam.jsp

Adding Handlers to a Service Control

Dealing with web services can sometimes require doing processing directly on the incoming and outgoing messages. The standard way of doing this is with a handler that is registered on either the client or the server. Handlers can inspect the incoming and outgoing messages, change the messages before they make it to the end point, log information, etc.

Most client technologies support some sort of handler, often using the standard JAX-RPC handler API. The Workshop service control is one such technology. It can sometimes be tricky to get the handlers registered correctly so I'll point out a couple different ways of doing it.

The primary way of registering a handler on service control is with the @ServiceControl.Handler annotation such as the following:

...
@ControlExtension
@ServiceControl.Handler(operation={"client.ClientHandler"})
public interface TargetServiceControl extends ServiceControl {
...

While the 'operation' attribute has an admittedly less than intuitive name, it's an array of strings that specify the class names of the handlers that will be called when the service control sends and receives messages. All handler classes must implement the javax.xml.rpc.handler.Handler interface. (The easiest way to do this is to subclass the GenericHandler)

Some people have had trouble with this annotation. If you're having trouble, another way to register the handlers is to do it programmatically on the JAX-RPC stub that underlies the service control. Here's an example of how to do that:

Stub stub = targetServiceControl.getStub();
HandlerRegistry reg = 
    (HandlerRegistry)stub._getProperty(WLStub.HANDLER_REGISTRY);
List handlers = new ArrayList();
handlers.add(new HandlerInfo(
          ClientHandler.class,
          new HashMap(),
          new QName[]{new QName("http://services","SomeHeader")}));
reg.setHandlerChain(
          new QName("http://services","TargetServiceSoapPort"),
          handlers);

This code first gets the stub from the service control, then grabs the HandlerRegistry from it. To actually register a handler with the handler chain you tell it what header the handler is interested in, as specified with the QName parameter on the "handlers.add..." line.

Finally the handler chain is put into the HandlerRegistry. The QName in this final line is the name of the port (not the portType) of the service this handler will listen to. The port name and the namespace it's contained in can be found in the WSDL used to generate the service control.

So while a little less convenient than the annotation, it does give you more control over how your handler is registered and can get around any issues you might find with the annotation.

For more information on the underlying JAX-RPC APIs, see the J2EE Documentation focused on the javax.xml.rpc.* packages.

In some of my coming posts I'll describe some of the uses of handlers you might encounter with the service control.

Workshop 9.2 Build Performance Trick

It's become clear that one of the builders in Workshop 9.2 can be costly to run on larger projects. This builder is just performing some validation, and it's a rare enough case that it's safe to disable this validation.

To turn off this validator, go to Project > Properties > Builders. On this page, uncheck the Control Validator builder. You will still get almost all of the control validation (red squiggles and problems view entries) since it's mostly run by the Java Builder. The Java Builder must remain enabled, of course.

The Control Validator just does a little bit of additional validation on top of the Java Builder, but since it's complex validation it can take a bit of time.

The Evils of Add External Jar

There are a lot of good features and options Eclipse provides to you as a developer. On the other hand, there are some that can lead you into trouble as well. One in particular that shows up throughout the IDE is the Add External Jars option.

With few exceptions, most developers these days don't work alone; they work in teams. Working in teams means using source code management systems and sharing code with other people on other machines. (Actually, working alone should typically mean using SCM as well, but that's a topic for another day).

What does this have to do with the Add External Jars option? The problem is that Add External Jars puts an absolute path into the project metadata--the same metadata that is used by all developers on different machines. Once you use this and end up with absolute paths in your project settings, you check in those project files and now everyone has to have the exact same paths on their system. And this is assuming you're not using different platforms where paths are of different formats. Then you're really out of luck.

The moral of the story is, don't use Add External Jars.

The alternatives are:

1. Use the Add JARs... option. This allows you to reference jars in the workspace, but I only ever use this to reference jars in the same project--typically in a "lib" directory set up in the root. These jars are usually checked into SCM along with the project.

2. If you don't want to check jars in, consider using an Eclipse classpath variable (Window > Preferences > Java > Build Path > Classpath Variables). The downside to this option is that each developer has to set up this variable in their IDE, but then by using the Add Variable... button the paths are relative to this configurable location.

3. You could package them as J2EE Libraries and add them that way as well. I won't go into detail about this option here, but will discuss it in a later post.

Start from Schema Web Services with Workshop 9.2

While start-from-WSDL web services get a fair bit of play these days, writing WSDLs by hand or even with a tool is not for the faint of heart. But for those of you wanting to stick with a set of common, well-defined data structures there's another approach that provides many of the same benefits--Start from Schema web services.

In this model you start from one or more XSD files allowing you to define your data structures. Then you proceed to build a normal Java web service with those structures. It's not full-on "Contract First" in the sense that you aren't defining your operations and bindings outside of Java, but you're defining an important part of the service as a contract. We're finding many customers who care a lot about a common set of structures while they're willing to define the operations and messages in Java, leaving WSDL generation to the tool.

Naturally I'm bringing this up because Workshop for WebLogic 9.2 provides the tools you need to use this model easily.

The Key - XMLBeans and the XMLBeans Builder

The basic steps are these:

- Create a project that has XMLBeans support enabled
- Create (or import) your schemas in the schemas directory
- Create a web service that uses the XMLBeans generated from the schemas as your parameters and return types.

Pretty simple, really. I showed how to enable XMLBeans Builder support in a previous post. This is the key. By putting your schemas in the schemas directory, they're effectively treated like source files and Java types (XMLBeans) are automatically created from those schemas in a similar way to class files being created from Java files. No extra manual generation steps, no wizards, it just happens (assuming you have Auto-build on, that is).

An Example

Let's take a very simple schema for the example:

<?xml version="1.0"?>
<xs:schema targetNamespace="http://myco.com/xml/types"
    xmlns:types="http://myco.com/xml/types"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified">

    <xs:complexType name="ext-customerType">
      <xs:sequence>
        <xs:element name="last-name" type="xs:string"/>
        <xs:element name="first-name" type="xs:string"/>
      </xs:sequence>
    </xs:complexType>

    <xs:element name="external-customer" 
              type="types:ext-customerType"/>
</xs:schema>

Now when I drop it into the schemas directory XMLBeans will be automatically generated for me. Here's what my .xbean_src directory looks like with the schemas compiled. Notice that the packages match the targetNamespace of the schema, and there are Java classes/interfaces matching the types and global elements (...Document classes) of the schema.

Next all you need to do is create a regular WebLogic Web Service and use these types as your parameters and return types. Here I've created a web service and am using the design view to edit the operations. Notice that the XMLBeans show up in code-assist just like any other Java class would, making for a convenient way to reference them:

When you generate a WSDL for this service you'll notice that your schema from which the XMLBeans were generated has been included in the <types> section rather than regenerating a new schema based off of the Java classes. Of course when you go back and edit your schema the changes will immediately be reflected in the Java classes, no need for a separate generation step. Thus you can easily iteratively develop your schemas along with your service as you go.

And that's really all there is to it.

May 2008

Search this blog:

Archives

April 2008
February 2008
December 2007
July 2007
June 2007
May 2007
March 2007
February 2007
January 2007
October 2006
September 2006
July 2006
June 2006
May 2006

Categories

Recent Entries

Event Server Developer Tools 2.1

Event Server Development Environment for Eclipse 2.0.1 Now Available

WebLogic Event Server 2.0 Development Environment for Eclipse Now GA