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).Read Vincent in: Container Client Interface
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.
-
Container Client Interface (16 messages)
- Posted by: Dion Almaer
- Posted on: July 28 2004 19:52 EDT
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.Threaded Messages (16)
- You know your famous when... by Rob Harrop on July 29 2004 12:08 EDT
- oops by Rob Harrop on July 29 2004 12:11 EDT
- Container Client Interface - a contribution by Kyle Downey on July 29 2004 12:51 EDT
- Container Client Interface - a contribution by Vincent Massol on July 29 2004 13:07 EDT
- should provide more than start/stop and deploy by Sanjiv Jivan on July 29 2004 13:38 EDT
- RE: Container Client Interface by Matt Raible on July 29 2004 14:34 EDT
- RE: Container Client Interface by Vincent Massol on July 29 2004 15:05 EDT
- RE: Container Client Interface by Billy Newport on July 29 2004 04:27 EDT
- RE: Container Client Interface by Jason Carreira on July 30 2004 11:00 EDT
- RE: Container Client Interface by Vincent Massol on July 29 2004 15:05 EDT
- Container Client Interface by Steve Lewis on July 29 2004 18:12 EDT
- Container Client Interface by Vincent Massol on July 30 2004 06:11 EDT
- Container Client Interface by Steve Lewis on July 30 2004 07:27 EDT
- Container Client Interface by Vincent Massol on July 30 2004 06:11 EDT
- Not sure what value this adds? by Nader Aeinehchi on July 30 2004 07:33 EDT
- Not sure what value this adds? by Vincent Massol on July 30 2004 09:15 EDT
-
Not sure what value this adds? by Nader Aeinehchi on July 30 2004 04:48 EDT
- Not sure what value this adds? by Steve Lewis on July 30 2004 05:20 EDT
-
Not sure what value this adds? by Nader Aeinehchi on July 30 2004 04:48 EDT
- Not sure what value this adds? by Vincent Massol on July 30 2004 09:15 EDT
-
You know your famous when...[ Go to top ]
- Posted by: Rob Harrop
- Posted on: July 29 2004 12:08 EDT
- in response to Dion Almaer
.. ervy refers to you by just your first name :)
Scary thing was I knew this was Vincent Massol straight away. -
oops[ Go to top ]
- Posted by: Rob Harrop
- Posted on: July 29 2004 12:11 EDT
- in response to Rob Harrop
ervy = every one!
My typing is dreadful -
Container Client Interface - a contribution[ Go to top ]
- Posted by: Kyle Downey
- Posted on: July 29 2004 12:51 EDT
- in response to Dion Almaer
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). -
Container Client Interface - a contribution[ Go to top ]
- Posted by: Vincent Massol
- Posted on: July 29 2004 13:07 EDT
- in response to Kyle Downey
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!). -
should provide more than start/stop and deploy[ Go to top ]
- Posted by: Sanjiv Jivan
- Posted on: July 29 2004 13:38 EDT
- in response to Dion Almaer
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 -
RE: Container Client Interface[ Go to top ]
- Posted by: Matt Raible
- Posted on: July 29 2004 14:34 EDT
- in response to Dion Almaer
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! -
RE: Container Client Interface[ Go to top ]
- Posted by: Vincent Massol
- Posted on: July 29 2004 15:05 EDT
- in response to Matt Raible
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. -
RE: Container Client Interface[ Go to top ]
- Posted by: Billy Newport
- Posted on: July 29 2004 16:27 EDT
- in response to Vincent Massol
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 -
RE: Container Client Interface[ Go to top ]
- Posted by: Jason Carreira
- Posted on: July 30 2004 11:00 EDT
- in response to Vincent Massol
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).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. -
Container Client Interface[ Go to top ]
- Posted by: Steve Lewis
- Posted on: July 29 2004 18:12 EDT
- in response to Dion Almaer
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 -
Container Client Interface[ Go to top ]
- Posted by: Vincent Massol
- Posted on: July 30 2004 06:11 EDT
- in response to Steve Lewis
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). -
Container Client Interface[ Go to top ]
- Posted by: Steve Lewis
- Posted on: July 30 2004 07:27 EDT
- in response to Vincent Massol
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 -
Not sure what value this adds?[ Go to top ]
- Posted by: Nader Aeinehchi
- Posted on: July 30 2004 07:33 EDT
- in response to Dion Almaer
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? -
Not sure what value this adds?[ Go to top ]
- Posted by: Vincent Massol
- Posted on: July 30 2004 09:15 EDT
- in response to Nader Aeinehchi
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). -
Not sure what value this adds?[ Go to top ]
- Posted by: Nader Aeinehchi
- Posted on: July 30 2004 16:48 EDT
- in response to Vincent Massol
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. -
Not sure what value this adds?[ Go to top ]
- Posted by: Steve Lewis
- Posted on: July 30 2004 17:20 EDT
- in response to Nader Aeinehchi
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