geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: deployment (oh, how I hate to go here...)
Date Tue, 08 Feb 2005 03:01:33 GMT wrote:
> IMHO, if partially starting the server means that a EAR/WAR/CAR can't be 
> deployed remotely then I don't think that is practical as a user may want 
> to build and deploy the CAR from a GUI PC/workstation (possibly using a 
> GUI deployment tool) to a remote headless server. 
> Does anyone have a link to some more info about CAR files?  I could only 
> find 

The CAR Aaron is referring to is a Configuration Archive which is a 
Geronimo concept and not a J2EE Application Client Archive as described 
by ModuleType. Sorry for the confusion.

I wrote a long mail summarizing my views on online vs. offline 
deployment back in Nov that goes into Geronimo packaging:

The intent behind a (Geronimo) CAR file is that it is a versioned, 
sealable artifact containing both code and configuration state that can 
be transported between Geronimo installations. It is the external form 
of a Configuration, which is a package of services that can be hosted by 
a Kernel.

A Configuration is startable if its codebase dependencies can be 
resolved (using the installation's Repository services) and all of the 
GBeans it contains (defined as a collection of GBeanInfo + GBeanState 
objects) can be instantiated and brought online in the STOPPED state. 
Individual GBean inside the Configuration may or may not be startable 
depending on whether their (service) references are resolvable.

The Kernel only knows about Configuration packages - it has no knowledge 
of user-land packaging artifacts such as J2EE WARs or EARs. The job of 
converting user-land artifacts into Configurations is done by a 
ConfigurationBuilder working in conjunction with a set of ModuleBuilders 
- the process of doing this is loosely called deployment. The 
ConfigurationBuilder can be as complex as needed to get this job done - 
it might be fairly simple like the one for service.xml files, it might 
be quite complex like the J2EE one.

To build a Configuration, a builder may need access to other 
Configurations on which the one being build has /code/ level 
dependencies. For example, to introspect an EJB class the EJB builder 
would require the javax.ejb.* classes to be available, just like the EJB 
itself would need them at runtime. Thus during the build process, the 
builder needs to resolve code dependencies declared by the target 
Configuration; however, it does not need to resolve /service/ 
dependencies such as the availability of other GBeans.

This allows "offline" deployment, for example from a PC/Workstation. The 
intention is that a user can build a (Geronimo) CAR file in that 
environment, sign, seal and deliver it, handing off to an enterprise 
configuration management/provisioning process. That same (sealed) CAR 
file can be sent to any Geronimo server running anywhere in the 
enterprise (or outside) with confidence that, assuming the necessary 
code and services are available at that site, it will run as intended.

This is aimed purely and simply at enterprise users who have to deal 
with a lot of configurations and installations; it is not a model aimed 
at supporting iterative build/test cycles on a single desktop.

For that we have "online" deployment where a running server actually 
hosts its own deployment framework. A developer can hand a user-land 
module and a plan to the server using some mechanism such as Maven or a 
JSR-88 client, have it build the Configuration in-situ and bring online 
autoamtically in that local server ready for testing. This, of course, 
relies on the server being running.

To me this is a fairly simple solution that addresses the different 
needs of the two communities. However, at this time only online mode 
really works; although offline mode can generate CAR files, we are 
missing a way to easily import them into the target server.


View raw message