Refactoring Deployment

[Jeremy Boynes <jb...@gluecode.com>]

One thing we have talked about in the past is the problem with having 
deployment classes in each module - for example, having the connector 
deployer in the connector module. The issue here is that due to 
classloader dependencies, the deployment code needs to end up in the 
Server module so that it can interact with the deployers in each module.

The proposed solution to this was to split each deployable module into 
two - a runtime module that contained everything needed to execute the 
components (e.g. the servlet or ejb containers) and another which 
contained the deployment code. This way we could have separate runtime 
and deployment configurations.

With Tomcat coming up to speed we will be adding another deployer so I 
think this would be a good time to do that refactoring - any thoughts?

--
Jeremy

Re: Refactoring Deployment

[Jacek Laskowski <jl...@apache.org>]

Jeremy Boynes wrote:

> One thing we have talked about in the past is the problem with having 
> deployment classes in each module - for example, having the connector 
> deployer in the connector module. The issue here is that due to 
> classloader dependencies, the deployment code needs to end up in the 
> Server module so that it can interact with the deployers in each module.
> 
> The proposed solution to this was to split each deployable module into 
> two - a runtime module that contained everything needed to execute the 
> components (e.g. the servlet or ejb containers) and another which 
> contained the deployment code. This way we could have separate runtime 
> and deployment configurations.
> 
> With Tomcat coming up to speed we will be adding another deployer so I 
> think this would be a good time to do that refactoring - any thoughts?

+1 (I'm not at all aware of the issues you mentioned, but as I don't 
want to learn things that may change before I have finished, please do 
so now).

> Jeremy

Jacek

Re: Refactoring Deployment

[Dain Sundstrom <ds...@gluecode.com>]

I'm working on the application client, which is another deployer 
also....

-dain

On Sep 15, 2004, at 5:18 PM, David Jencks wrote:

> +100
>
> david jencks
>
> On Sep 15, 2004, at 4:56 PM, Jeremy Boynes wrote:
>
>> One thing we have talked about in the past is the problem with having 
>> deployment classes in each module - for example, having the connector 
>> deployer in the connector module. The issue here is that due to 
>> classloader dependencies, the deployment code needs to end up in the 
>> Server module so that it can interact with the deployers in each 
>> module.
>>
>> The proposed solution to this was to split each deployable module 
>> into two - a runtime module that contained everything needed to 
>> execute the components (e.g. the servlet or ejb containers) and 
>> another which contained the deployment code. This way we could have 
>> separate runtime and deployment configurations.
>>
>> With Tomcat coming up to speed we will be adding another deployer so 
>> I think this would be a good time to do that refactoring - any 
>> thoughts?
>>
>> --
>> Jeremy
>>

Re: Refactoring Deployment

[David Jencks <dj...@gluecode.com>]

+100

david jencks

On Sep 15, 2004, at 4:56 PM, Jeremy Boynes wrote:

> One thing we have talked about in the past is the problem with having 
> deployment classes in each module - for example, having the connector 
> deployer in the connector module. The issue here is that due to 
> classloader dependencies, the deployment code needs to end up in the 
> Server module so that it can interact with the deployers in each 
> module.
>
> The proposed solution to this was to split each deployable module into 
> two - a runtime module that contained everything needed to execute the 
> components (e.g. the servlet or ejb containers) and another which 
> contained the deployment code. This way we could have separate runtime 
> and deployment configurations.
>
> With Tomcat coming up to speed we will be adding another deployer so I 
> think this would be a good time to do that refactoring - any thoughts?
>
> --
> Jeremy
>