CCI: Container Client Interface
[ vmassol ] 20:56, Saturday, 24 July 2004

11/08/2004 update: The project is about to start on Codehaus and is now named Cargo.

Note: There is also an article and a discussion thread on TheServerSide about this inititative

Here's a new idea for an open source project I'd like to start. It could be called CCI (Container Client Interface). It would aim at providing a simple Java API to start/stop/configure/deploy Java containers (In the first version the goal would be to support J2EE containers). This Java API could then be used by lots of other projects (Ant tasks, Maven plugins, IDE plugins, Cactus, etc).

The inspiration comes from the Cactus project, which already provides an extensive API to perform such tasks. The goal is to refactor the Cactus Ant API, remove anything related to Cactus and make it a standalone project called CCI

Here's an integraton test showing what the API could look like:

    public void testStartWithOneWarDeployed()
    {
         Container container = new Resin3xContainer();
         container.setHomeDir("/apps/resin-3.0.8");
         container.setPort(8080);
         container.setInstallDir(new File("target/resin3x"));
 
         WAR war = new WAR("src/testinput/simple.war");
         URL pingURL = new URL("http://localhost:" + PORT + "/simple/index.html"); 
         war.setPingURL(pingURL);
 
         container.addDeployable(war);
 
         ContainerRunner runner = new DefaultContainerRunner(container);
 
         runner.start();
         assertTrue("Container not started yet!", new HttpUtils().ping(pingURL));
         
         runner.stop();        
         assertFalse("Container not stopped yet!", new HttpUtils().ping(pingURL));
     }

As you can see there are several main Objects/Interfaces:

  • Container: This the main object that provides the API to start/stop the container.
  • WAR: A WAR archive to be deployed in the container. Inherits from Deployable. There will be other types later on (WAR, EAR, RAR)
  • ContainerRunner: Athough a container can be start ed without a container runner, the container runner provides advanced feature like starting the container in a different thread, verifying if the container is already started, waiting till the container is started, waiting till the container is stopped, etc.

Note that the ping URLs are the URLs that will be pinged by the ContainerRunner object to ensure the container has finished starting. Thus, after container.start() has finished executing you can be sure the container is started and the archives have been deployed and are ready for servicing requests. A better solution in the future will be to use JMX to ensure the container has finished starting. However, all containers do not yet support this feature.

A shorthand code version to start Resin 3.0.8 could look like:

        Container container = new Resin3xContainer("/apps/resin-3.0.8");
        container.setInstallDir("target/resin3x");
        container.addDeployable(new WAR("src/testinput/simple.war"));
        container.start();

This is just a taste of what he CCI API could look like. Let me know what you think!


Comments

but many IDE(eclipse,jbuilder etc.) can start/stop/deploy java project when click one menu.

i don't know where CCI API can use? i think that it's two usebility:

1. you can agile manage/substitute Java containers when use XML configuration
2. you can write program to manage container when you need other java project's function

--befresh, July 16, 2004 05:11 AM

> but many IDE(eclipse,jbuilder etc.) can start/stop/deploy java project when click one menu.

That's exactly the point! :-) The persons who wrote these plugins had to code a lot to them working. I'm suggesting to have a common framework for that to make it easier to develop such plugins. Of course, it won't be adopted overnight but I feel there's a possibility it may be adopted as it's a Java API and thus it can be reused in all contexts.

--Vincent Massol, July 16, 2004 07:01 AM

I would have tons of uses for this kind of library. I could make a automated test case that my EAR is deployed ok. Furthermore I could make automated test cases for my ejbs without having to manually start the container. The benefit of having the container start with the test case is that the whole thing could be part of cruise control build.

--Janne, July 29, 2004 11:49 PM

Sounds interesting. I vote for the really simple shorthand version. Not sure what a "ContainerRunner" would buy you over the Container interface. I'd prefer the Container() constructor take and XML file or stream with all the config settings in it so I could verify a Deployable against multiple Container types.

--gerryg, August 2, 2004 11:45 PM

Hi Vincent,

Thought you might be interested in JAM (JavaGen Ant Modules), it does what you’re proposing in pure Ant and already supports several app servers in a modular fashion. The feedback I’m getting is that people like it because they can get their builds working without having to resort to Jelly or Java. JAM utilizes Maven’s POM and repository for classpath and packaging and contains several unit test modules, including one for Cactus (great framework by the way, thanks for your work on it!).

--Richard Easterling, August 3, 2004 09:42 AM

Hi Richard,

Thanks for your feedback. However the CCI project is proposing a *Java* API. BTW, the CCI project is *already* implemented inside the Cactus project and it alreayd offers a pure Ant and Java APIs. The point here is to refactor this out of Cactus and propose and standalone project focusing only on starting/stopping/configuring containers.

One of the goal is to offer this API to Ant developers, Maven developers, JAM developers so that they can easily create plugins for starting/stopping/configuring containers.

Thanks for the praise on Cactus :-)

--Vincent Massol, August 7, 2004 01:25 PM

Gerry, the ContainerRunner is a kind of watchdog. It starts the container in a spearate thread, and polls the container to verify if the container is started/stopped. I think it has to be something of a higher level than the container because it is generic to all containers and is a runner of container.

As for the container configs, I'm still unsure. The goal of this project is to create a *Java* API not an XML or properties one... That said, I'm also happy to add some helper classes/client classes later on if required.

Honestly, I'm still unsure about the container configs. There are several possibilities:
1/ Java properties
2/ Ability to pass the container config files directly through a Java property (thus pushing the responsiblity of config to the user)
3/ Yet another config format (XML, Stream, etc) as you're proposing.

I'm still hesitating between 1 and 2. But we'll see what happens when people start using it.

Thanks

--Vincent Massol, August 7, 2004 05:57 PM

Hi Vincent,
perhaps jboss might provide some inspiration with the idea of getting JMX involved.. Might be overkill to consider the container a managable attribute, but it might be useful?
You could then just regard any properties to just be attributes, although I think just adhering to the javabeans naming convention would be useful, but like you said there are three options that all have good and bad points.
But I like the idea of a generic container interface rather than one that deals with J2EE specific terms. For instance we deal with integration products (webMethods in particular) and some of these pseudo J2EE products like ATG which have their own extensions to the J2EE ideas. For instance webmethods deals with the notion of "packages" which are the equivalent of a jar or war, and an interface which talked of WARs and so on would be unsuitable.
regards,
Nathan Lee

--Nathan Lee, August 9, 2004 02:51 PM
Post a comment









Remember personal info?