geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jer...@coredevelopers.net>
Subject Re: Who's in charge of deploying EARs?
Date Tue, 06 Jan 2004 16:17:10 GMT
Aaron Mulder wrote:

> On Tue, 6 Jan 2004, Jeremy Boynes wrote:
> 
>>Yeah, sorry - it's taking longer than expected but I have to work as 
>>well :-)
> 
> 
> 	If you think it's going to be a problem, we could always put it in 
> a branch so more people can work on it before it's "done".
> 
> 

I'm trying to get to that stage. The issue isn't really with my stuff 
but that I am dependent on changes that Dain is making to the GBean that 
would break everything.


>>It is very close to the 88 model.
>>
>>There are three phases: "deploy", "distribute" and "run"
>>
>>In the "deploy" phase, a ConfigurationBuilder takes a set of URLs and 
>>runs them by a set of Deployers to build a Configuration. This is a 
>>jar-formatted file containing code plus a set of persisted GBeans. I'm 
>>thinking of calling it a "CAR" file - any thoughts?
>>
>>Because it is a single file it is easy to copy between nodes (somehow). 
>>The "distribute" phase does just that; it is copied to each target which 
>>then stores in a local ConfigurationStore.
>>
>>Once all the distribution has happened, then the various targets can be 
>>started by bringing the Configuration online. This will create a new 
>>classloader, unpersist the GBeans and then start them all (with the 
>>DependencyService sorting out the start order).
> 
> 
> 	I guess my concern is that the JSR-88 "distribute" stage (which
> here seems to be deploy + distribute) should do validation.  So around the
> time of CAR assembly, we want to make sure that all the DDs are valid, all
> the required code is present, the classes have the right methods and
> superclasses, all resource refs are resolved, etc.  That can be done once,
> by the ConfigurationBuilder (but it needs a live ClassLoader to do it).  

Yes, this is all part of "deployment" as J2EE defines it.

The ConfigurationBuilder actually runs in three steps:
* work out the combined classpath for the configuration and build a
   ClassLoader for it
* build the GBeans
* construct the CAR, including any needed classpath entries and the
   persisted form of the GBean state

> Then when we distribute it to servers (however), they may do more
> validation if there's anything different from server to server (i.e. if
> there are different security realms per server, they could validate the
> security mappings, but there may be nothing to do here).

The intention is that the CAR is distributable from server to server so 
no further validation would be performed by the configuration system. 
However, the GBeans themselves can fail to start (for any number of 
reasons). If this happens, then the intention is the configuration 
change gets rolled back - the new configuration would be unloaded and if 
it was replacing one that would be restarted (which could also fail)).

> 	Bottom line, when you get to the "run" stage (which I assume 
> corresponds to calling "start" on the JSR-77 MBean)

It involves creating a classloader for the code in the CAR, loading the 
persisted GBeans and then calling "start".

> I want the only 
> possible failure to be that some resource that we lazily resolve isn't 
> present at runtime.  I don't want you to get that far only to discover 
> that you misspelled the EJB class name in your DD, or whatever.
> 	Is that pretty much what you have in mind?
> 

Yes

-- 
Jeremy

Mime
View raw message