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:

• Eclipse server definition sample
• Server definition explained

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.

Anchoring Petals in Eclipse using WTP Server Tools – part 0

Hi,

I’m starting a series of articles to explain the creation of tools to define and interact with Petals servers through the Eclipse server view.
This is the first step to new tools around Petals: obviously, Petals servers will be used to debug Petals components and Java services, query the Petals technical regitry. But Petals servers will also be the basis for topology related tools: architecture modeling, definition and management of Petals projects, introspection and diagnostic of Petals servers and topologies.

This is definitely an important step that must be done carefully and correctly.
Without being too arrogant, I think I have quite a good experience in Eclipse. I mean, I have programmatically worked with SWT, EMF, GEF, GMF, JDT (the Java tooling), the Common Framework Navigator, WTP SSE (source editing), dynamic registrations of plug-ins extensions, plus the usual Eclipse mechanisms, e.g. builders, natures… And despite this, I must confess I have never worked with something so much complex than WTP server tools. Their concepts can be confusing, the existing plug-ins are not that simple. And applying it to YOUR server is far from being trivial. Generally, it doesn’t take me so long to understand an Eclipse API or mechanism. I guess the language may also have a responsability in this (I was used to consider runtime and server as – almost – equivalent words).

This is why I want to write these articles.
At least, it will help me to explain to Petals developers why I made some choices.
And mayit will help others to implement their own server support into Eclipse.

To end this first article, here are few but useful links and readings:

• The official web page of WTP server tools.
• The API overview explains the concepts of WTP server tools.
• The server tools overview page has links to presentations (EclipseCON and others).
• One very good page was made on Apache Service Mix’s wiki about how WTP server tools could be used for this ESB.
• The server tools CVS for examples

Close a welcome page programmatically

Hi.

Here is a small snippet that may avoid some waste of time.
I spent almost 3 hours to find a solution. This is why I share it here.

Let’s first introduce what I wanted to do.

I have a welcome page, which extends IntroPart and is able to launch wizards on user actions. I coded it manually. It does not rely on the CustomizableIntroPart class. What I wanted to do was to close it when a wizard launched from this page had completed. This behavior is visible in the default welcome page of Eclipse. When you click “Go to workbench”, the welcome page is closed and a perspective is shown.

The first idea was to programmatically close the view that embeds the welcome page after the wizard has executed (with IWorkbenchPage#hideView( String )).
I did try, and it was unsuccessful. The workbench shows an empty widget, and no perspective is shown.

I then tried to close the page in IntroPart#setStandBy( boolean ). Unsuccessfully.
I then tried to reuse what is implemented in the org.eclipse.ui.intro plug-in, in the method IntroURL#switchToLaunchBar().
Therefore, one solution I tried to close the Eclipse welcome page is:

IntroURL url = new IntroURLParser( "http://org.eclipse.ui.intro/" + IntroURL.SWITCH_TO_LAUNCH_BAR );
url.execute();

Still unsuccessful.

In fact, no matter what you use, if the welcome page tries to close itself, it will fail.
The solution was to make my welcome page implement IPartListener and register itself on its page.
When the page is deactivated (when it losts the focus), the welcome page is closed, using:

PlatformUI.getWorkbench().getIntroManager().closeIntro( part );

That was that simple!