Vincent has had some thoughts on a Container Client Interface that is an API that allows you to start/stop/configure/deploy Java containers. In this entry Vincent explains what he is thinking about.

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.

Read Vincent in: Container Client Interface

.. ervy refers to you by just your first name :)

Scary thing was I knew this was Vincent Massol straight away.

ervy = every one!

My typing is dreadful

This code does it, in part. I no longer maintain the package it's part of and would have no problem contributing it if it's at all useful.

http://cvs.sourceforge.net/viewcvs.py/amberarcher/san_jacinto/module/j2ee/management/src/share/classes/org/amberarcher/j2ee/management/

By the way the CCI is the name for the Java Connector Architecture's client interface. Might want to pick another.... And finally, any such project probably wants to take advantage of JSR-88 for deployment rather than rolling your own (as I did prior to that spec).

Before everyone starts asking... :-)

1/ No, the goal of the CCI project is not to create yet another deployment API. There's already JSR77/88 for this. CCI is about providing an API to start/stop containers (including in-place startup).

2/ Yes, the name will have to be changed as I'm sure there's a Sun trademark on CCI. *sigh* I had the same issue when I first created J2EEUnit which became Cactus... ;-). Ideas are welcome.

3/ This is really an early announcement. I'm currently looking for a home for CCI. I do have a first working implementation and it'll quite easy and fast to port the Cactus code to CCI. ATM, there's no mailing list, no web site, etc. So please be patient and everything should be set up in about 1 week from now (Hey, I'm still on holiday!).

I think such a project would be useful however there are some issues related to configuration and deplyoment which I still find annoying. Details can be found at the URL below. It would be nice if this project addresses some of these issues as well.

http://sourceforge.net/forum/forum.php?thread_id=1117835&forum_id=250340

I'm assuming you're going to provide Ant tasks for this - and that its integration into Cactus will be transparent? What I'd really like to see in the Ant tasks is that you can set the app server as a property - and easily switch from using one server to another. Can't wait to try it out!

I'm assuming you're going to provide Ant tasks for this - and that its integration into Cactus will be transparent? What I'd really like to see in the Ant tasks is that you can set the app server as a property - and easily switch from using one server to another. Can't wait to try it out!

Yes, I'm planning to provide some Ant tasks. I don't think that it'll be transparent of the Cactus tasks. It'll be deprecated and remain for some time but a new one using CCI will take over. I think that makes most sense because the Cactus projects wants to be able to leverage instantaneously any new container support added in the CCI project.

As for the property, it's very easy to provide a ContainerFactory. But I guess you're talking about the Ant task. I'm not sure it's feasible as each container may have some specific attributes. We'll see. I'll keep it in mind. Just not sure it's doable.

Thanks.

How would this compare to just leveraging something like OSGI 3.0++ from the eclipse 3.0 framework? Are you addressing class loaders, dependencies between components etc?

Thanks

I'm assuming you're going to provide Ant tasks for this - and that its integration into Cactus will be transparent? What I'd really like to see in the Ant tasks is that you can set the app server as a property - and easily switch from using one server to another. Can't wait to try it out!

Yes, I'm planning to provide some Ant tasks. I don't think that it'll be transparent of the Cactus tasks. It'll be deprecated and remain for some time but a new one using CCI will take over. I think that makes most sense because the Cactus projects wants to be able to leverage instantaneously any new container support added in the CCI project.As for the property, it's very easy to provide a ContainerFactory. But I guess you're talking about the Ant task. I'm not sure it's feasible as each container may have some specific attributes. We'll see. I'll keep it in mind. Just not sure it's doable.Thanks.

So just make it possible to dynamically set the container to manage (read from a property) and also make it where you can tell it a properties file to load for additional container-specific settings (or it can just read them from ant properties, which can be dynamically set up based on which container you're using).

Very interesting. I did something fairly similar, starting up a JBoss MBeanServer in a JUnit test. Bringing the container to the test, rather than bringing the test to the container (like Cactus). I got the idea from Andrew Oliver, so it's not really my idea, but I think the idea is very powerful.

I have a patch on JBoss's sourceforge site, but I was having some classloading issues, so I'm sort of at a standstill right now.

Please let us know where it'll be hosted, etc.
Steve

Bringing the container to the test, rather than bringing the test to the container (like Cactus).

Exactly! That said Cactus does bring the container to the test... ;-) (with the <cactus> Ant task).

Yeah. I hadn't thought of that, but you're right. As long as the unit test can execute inside the container, and know it's started by the time the test executes, it doesn't really matter.

My personal preference is to have fewer steps, and I think bringing the container to the Unit Test can do that. Cactus is very nice technology, though. I think there are many things in Java floating around that are aiming at simplification, and an idea like this is going to help.

Steve

There are several container systems that are capable of managing the life-cycle of components(including containers). For example, take a look at Apache Avalon Merlin that has a strong and flexible way of doing it.

Have I totally misunderstood Vincent's point?

There are several container systems that are capable of managing the life-cycle of components(including containers). For example, take a look at Apache Avalon Merlin that has a strong and flexible way of doing it.Have I totally misunderstood Vincent's point?

Hi Nader. AFAIK, Merlin *is* a container. The goal of CCI is simply to offer an API to start/stop *existing* containers. The goal is not to create another container nor it is to create an API for containers to write against (that would be Avalon, Pico/Nano, Hivemind, etc).

Merlin *is* a container. The goal of CCI is simply to offer an API to start/stop *existing* containers. The goal is not to create another container nor it is to create an API for containers to write against (that would be Avalon, Pico/Nano, Hivemind, etc).

Hi Vincent, thanks for your clarification. Please let me make some notes here.

Firstly, in my humble opinion, containers and usual components could be treated similarly from a life-cycle point of view . The life-cycle of any computational entity (including containers) can be characterized by incarnation, life-time and ethernalization (the idea is borrowed from Merlin). For a simple entity, incarnation could be "init", life-time could be "start" and ethernalization could be "stop". For more complex entities, there could be several additional stages, say, load, start and contextualize.

Secondly, any such computational entity may need an environment, e.g. configuration and context. Environment could literally be anything the component needs (file system, directory, images etc). So basically, the entity (including a container) needs to obtain an environment, either by asking for it (service lookup), or by being given to(service injection).

Thirdly, such computational entities usually have a life-cycle(as Merlin defines). Life-cycle could be singleton, thread etc.

Forth, IMHO, I am not sure that it is possible to define a "specific" interface that it is good enough for all possible containers out there. However, if you rather define a generic interface based on the above suggestions, you may end up with an interface that is good enough for most containers.

Fifth, experience shows that a generic code must at the end be specialized by the client code (there is no free lunch). Good news is that this challenge could be solved either by configuration (XML) or by Java Generics. By client code, I mean the code that initializes, starts and stops the container.

For example, Merlin, provides many of the above features and more. I am sure there are several other systems that provide more or less the same. Just for the record, I do not work for Apache. I have simply admired Merlin's effort for a while.

Makes sense.

If there was a sufficiently generic way to programmatically start up a container, I think that's the idea. Not all containers have ways to programmatically start the container. Not as easy as something like PicoContainer :)

Steve