Anchoring Petals in Eclipse using WTP Server Tools – part 1

Implementation types

Let’s first introduce the different ways to register a server in WTP server tools.
Basically, there are two ways:

  • Hard-coded: you use WTP extensions-points and API. It implies Java programming.
  • XML: you define the server properties as a XML file that you register through an extension point. The GUI and properties will be generated and handled from this XML file.

For the XML approach, you can check these two links:

It is clearly the most simple way to register a server definition into Eclipse. OW2 JOnAS used it for its version 4.x.
The hard-coded approach is reserved for full-control and/or specific behaviors.

The XML approach was once used to define Petals servers.
About three years ago, Cap Gemini people created Eclipse plug-ins for Petals. There was a Petals server definition in it.
When I had to work on the Petals support into Eclipse, my first reflex was to start on this basis and update the serverdef file. Unfortunately, it revealed some weakenesses.

This brings us to talk about Petals specifics and somehow limitations to determine what is the best approach.

Petals’ needs

Petals contributions

Petals implements the JBI specification.
A Petals server accepts many kinds of contributions. These contributions are listed by the specifications and they must have a given structure. For some of them, moving from the workspace structure to the deployment structure can be a complex operation. For Petals components, this operation is generally made by Maven. For Petals service-units, this operation is generally made by the Eclipse plug-ins.

Therefore, deploying projects (WTP server tools would say modules) to Petals relies on and includes different backgrounds.
Integrating this packaging into a XML approach is not very convenient, unless you use ANT. Using ANT would require not to depend too deeply on Eclipse mechanisms.

Communications with Petals

There are two ways to communicate with Petals.
The first one relies on JMX. The second one relies on web services, that act as a proxy to JMX.

Why add web services? Well, Petals is a distributed ESB. We have users and clients who have several deployed nodes. And it appeared JMX was sometimes a problem to configure firewalls in systems. From this point of view, web services were more convenient.

Local and remote servers

One last aspect is that we want to be able to define local and remote servers.
Debugging and deployment things will obviously rely on local instances. But registry queries and diagnostic will be available on any server.
This is why our approach has to deal with both kind of Petals servers.

The .locked file

When Petals is running, or was improperly stopped, the install directory contains a “.locked” file.
When this file exists, no instance of Petals can be started.

If you use the XML approach, and that this file exists, the start server command fails, showing an exception with no cause explained.
To handle these files, a hard-coded approach is required, at least to implement the start command.

Conclusion

Clearly, we have important needs with respect to controlling interactions with Petals servers.
Besides, the .locked mechanism is very difficult to handle with a XML approach.

This is why I will try my luck with the hard-coded approach.


About this entry