offline deployment?

[toby cabot <to...@caboteria.org>]

Hi Folks,

I guess it's possible that I'm the only person that used offline
deployment, at least I don't see a lot of people clamoring to bring it
back.  It's very useful for me, though, so I'd like to find out if
there's a possibility of bringing it back onto HEAD (and hopefully the
1.0 branch, too).  I'll probably need to hack something for my needs
but I'd just as soon do it in a way that's Geronimo-savvy.

>From discussion on this list it looks as if the preferred approach is
to try to use the same approach that the build-time maven plugins do.
>From my naive reading of the code, it looks as if that happens in two
passes: first the geronimo-packaging-plugin takes a deployable
resource (ear, war, etc) and generates a configuration archive from
that, then the geronimo-assembly-plugin moves the car into the
ConfigurationStore.  The configurations are mentioned in config.xml
(hand-coded?) which causes them to get started when Geronimo runs.  I
see notes in the code that the packaging plugin uses the Maven
repository, so in order to work on machines without Maven I imagine
that we'd need to use the Geronimo repository instead.

Is this more-or-less on the right track?  I'd appreciate any tips or
pointers, especially if I'm about to head off in the wrong direction.

Thanks,
Toby

Re: offline deployment?

[toby cabot <to...@caboteria.org>]

On Tue, Jan 03, 2006 at 03:58:55PM -0800, Dain Sundstrom wrote:
> Will the hot deployment directory satisfy you needs?

I tried to think of an approach using hot deployment that would work,
but none are as clean as offline deployment.  But I'm probably a
corner case: I use Geronimo embedded in a system with lots of other
software around it, running in a sealed box rather than a typical
PC-like environment.  I cross-develop; with offline deployment I can
distribute my application into Geronimo during the build process, then
move it to a target machine and run it on a read-only partition.  Of
course I have to move various logs, etc to /var but that's easily done
by tweaks to various plan.xml files.  I've also done some experiments
recently to allow Geronimo to have multiple config-stores so I can
have my core software in read-only storage and deploy other stuff to
/var.

Using hot deployment would be much more complex as I'd have to modify
the hot deployer to read from /var and deploy to a read-write config
store.  It also leaves a lot of processing to the target machines that
currently happens on development machines.  It's do-able but I like
that with offline distribute my code is in a read-only config store so
it can't be messed with.

I've got a workaround with online distribution but it's a clumsier
build process since I have to fire up the server, wait some arbitrary
time for the deployer to become available, distribute, and shut down
the server.  I can probably live with that but offline distribution is
much cleaner.

I recognize that my requirements aren't typical so I'm happy to (as
with multiple config stores) do some work to help make it happen.  I
just don't want to go off half-cocked and end up with something that's
a crime against the Geronimo architecture.  What do you think of the
approach that I mentioned in my previous email?  Am I barking up the
right tree?

Thanks,
Toby

Re: offline deployment?

[Dain Sundstrom <da...@iq80.com>]

Will the hot deployment directory satisfy you needs?

-dain

On Jan 3, 2006, at 7:34 AM, toby cabot wrote:

> Hi Folks,
>
> I guess it's possible that I'm the only person that used offline
> deployment, at least I don't see a lot of people clamoring to bring it
> back.  It's very useful for me, though, so I'd like to find out if
> there's a possibility of bringing it back onto HEAD (and hopefully the
> 1.0 branch, too).  I'll probably need to hack something for my needs
> but I'd just as soon do it in a way that's Geronimo-savvy.
>
>> From discussion on this list it looks as if the preferred approach is
> to try to use the same approach that the build-time maven plugins do.
>> From my naive reading of the code, it looks as if that happens in two
> passes: first the geronimo-packaging-plugin takes a deployable
> resource (ear, war, etc) and generates a configuration archive from
> that, then the geronimo-assembly-plugin moves the car into the
> ConfigurationStore.  The configurations are mentioned in config.xml
> (hand-coded?) which causes them to get started when Geronimo runs.  I
> see notes in the code that the packaging plugin uses the Maven
> repository, so in order to work on machines without Maven I imagine
> that we'd need to use the Geronimo repository instead.
>
> Is this more-or-less on the right track?  I'd appreciate any tips or
> pointers, especially if I'm about to head off in the wrong direction.
>
> Thanks,
> Toby

Re: offline deployment?

[Jeff Genender <jg...@apache.org>]

No you are not the only one.  This has been a huge discussion, and there
is definitely a need for this functionality.  IIRC, I think David Jencks
was going to build a similar type tool after the 1.0 release.  he should
be able to comment on this...

Jeff

toby cabot wrote:
> Hi Folks,
> 
> I guess it's possible that I'm the only person that used offline
> deployment, at least I don't see a lot of people clamoring to bring it
> back.  It's very useful for me, though, so I'd like to find out if
> there's a possibility of bringing it back onto HEAD (and hopefully the
> 1.0 branch, too).  I'll probably need to hack something for my needs
> but I'd just as soon do it in a way that's Geronimo-savvy.
> 
>>>From discussion on this list it looks as if the preferred approach is
> to try to use the same approach that the build-time maven plugins do.
>>>From my naive reading of the code, it looks as if that happens in two
> passes: first the geronimo-packaging-plugin takes a deployable
> resource (ear, war, etc) and generates a configuration archive from
> that, then the geronimo-assembly-plugin moves the car into the
> ConfigurationStore.  The configurations are mentioned in config.xml
> (hand-coded?) which causes them to get started when Geronimo runs.  I
> see notes in the code that the packaging plugin uses the Maven
> repository, so in order to work on machines without Maven I imagine
> that we'd need to use the Geronimo repository instead.
> 
> Is this more-or-less on the right track?  I'd appreciate any tips or
> pointers, especially if I'm about to head off in the wrong direction.
> 
> Thanks,
> Toby

Re: offline deployment - status

[David Jencks <da...@yahoo.com>]

On Jan 19, 2006, at 12:46 PM, toby cabot wrote:

> I've made some progress on this and it seems to work OK for basic j2ee
> deployments, except for the problem below.  It's not pretty but it
> does what I need for the time being.  If anyone else is interested in
> this I could clean it up and post it to the list, and if anyone's got
> a tip about the problem below I'd be mucho grateful.

I'd really appreciate it if you would open a jira and keep your  
progress posted as patches to it.
>
> On Tue, Jan 10, 2006 at 02:01:08PM -0500, toby cabot wrote:
>> It's all good until the code reaches the SwitchingModuleBuilder,  
>> which
>> is configured by default to deploy to Tomcat, so since I'm using  
>> Jetty
>> it fails to find a builder and I get "foo.war is not a war" messages.
>> It looks as if SwitchingModuleBuilder's defaultNamespace is  
>> overridden
>> in assemblies/j2ee-jetty-server's config.xml, but I'm not clear on  
>> how
>> to override this parameter when I'm in a command-line environment.
>> I'm not even clear on how this gets overridden when the plugin is run
>> in a configs/*-jetty directory.  Pointers appreciated.

I'm not sure I have the whole context here, but basically you should  
use the web container specific plan namespaces to point out which  
container you want to target.  This is what we do in the configs, so  
there is a daytrader-jetty,  a daytrader-tomcat, etc etc etc.  If  
this doesn't answer your question right away please explain further :-)

thanks
david jencks

>
> Thanks,
> Toby

Re: offline deployment - status

[toby cabot <to...@caboteria.org>]

I've made some progress on this and it seems to work OK for basic j2ee
deployments, except for the problem below.  It's not pretty but it
does what I need for the time being.  If anyone else is interested in
this I could clean it up and post it to the list, and if anyone's got
a tip about the problem below I'd be mucho grateful.

On Tue, Jan 10, 2006 at 02:01:08PM -0500, toby cabot wrote:
> It's all good until the code reaches the SwitchingModuleBuilder, which
> is configured by default to deploy to Tomcat, so since I'm using Jetty
> it fails to find a builder and I get "foo.war is not a war" messages.
> It looks as if SwitchingModuleBuilder's defaultNamespace is overridden
> in assemblies/j2ee-jetty-server's config.xml, but I'm not clear on how
> to override this parameter when I'm in a command-line environment.
> I'm not even clear on how this gets overridden when the plugin is run
> in a configs/*-jetty directory.  Pointers appreciated.

Thanks,
Toby

Re: offline deployment?

[toby cabot <to...@caboteria.org>]

On Wed, Jan 04, 2006 at 10:12:00AM -0800, David Jencks wrote:
> Unless someone twists my arm severely I was planning on looking at  
> this again after 2 other items, jetspeed integration and a  
> transaction manager patch: if you wanted to get started on this first  
> I'd be very happy :-).

I've started messing around with this and hit a snag.  I've made a new
jar called "offline.jar" that's pretty much a clone of the existing
deployer.jar 'cept it runs a different main class, which itself is
pretty much a clone of the existing deployer main class.

It's all good until the code reaches the SwitchingModuleBuilder, which
is configured by default to deploy to Tomcat, so since I'm using Jetty
it fails to find a builder and I get "foo.war is not a war" messages.
It looks as if SwitchingModuleBuilder's defaultNamespace is overridden
in assemblies/j2ee-jetty-server's config.xml, but I'm not clear on how
to override this parameter when I'm in a command-line environment.
I'm not even clear on how this gets overridden when the plugin is run
in a configs/*-jetty directory.  Pointers appreciated.

Thanks,
Toby

Re: offline deployment?

[David Jencks <da...@yahoo.com>]

On Jan 3, 2006, at 7:34 AM, toby cabot wrote:

> Hi Folks,
>
> I guess it's possible that I'm the only person that used offline
> deployment, at least I don't see a lot of people clamoring to bring it
> back.  It's very useful for me, though, so I'd like to find out if
> there's a possibility of bringing it back onto HEAD (and hopefully the
> 1.0 branch, too).  I'll probably need to hack something for my needs
> but I'd just as soon do it in a way that's Geronimo-savvy.

It's definitely something we need in some form.
>
> From discussion on this list it looks as if the preferred approach is
> to try to use the same approach that the build-time maven plugins do.
> From my naive reading of the code, it looks as if that happens in two
> passes: first the geronimo-packaging-plugin takes a deployable
> resource (ear, war, etc) and generates a configuration archive from
> that, then the geronimo-assembly-plugin moves the car into the
> ConfigurationStore.  The configurations are mentioned in config.xml
> (hand-coded?) which causes them to get started when Geronimo runs.  I
> see notes in the code that the packaging plugin uses the Maven
> repository, so in order to work on machines without Maven I imagine
> that we'd need to use the Geronimo repository instead.
>
> Is this more-or-less on the right track?  I'd appreciate any tips or
> pointers, especially if I'm about to head off in the wrong direction.

That's about right.  I tried to make both the packaging and assembly  
plugins modular so that the class that does the work accepts  
arbitrary repository and config-store implementations so that all  
that is needed for the offline config-builder or assembler is to  
construct something using the geronimo repo and config store rather  
than the maven ones.  My idea was to control these plugins primarily  
with a properties file, but allowing overrides using command line  
properties.  I recall writing a primitive version of the command line  
packager but never tested it and I'm not sure if I committed it  
before my hard drive broke.

Something similar should work for the assembler.  One question I have  
about this is, where do the dependencies come from?  The maven  
assembly plugin makes sure all the dependencies for the config are  
copied from the maven repo into the geronimo repo.  I guess a command  
line version of this should fail if the dependencies aren't already  
in the repo?  Or should it accept some other repo anyway?  Or use a  
remote maven repo?  I don't know.

One missing piece that perhaps can be added to the assembly plugin as  
well is modification of config.xml.  I suppose a good start would be  
to have a flag that indicates whether the config should be loaded or  
not, and, similarly to the online deployer, either add an element to  
config.xml or set load="true" if the flag says to load the config.

Unless someone twists my arm severely I was planning on looking at  
this again after 2 other items, jetspeed integration and a  
transaction manager patch: if you wanted to get started on this first  
I'd be very happy :-).  Command line tools are not something I know  
how to make useable so I'm sure anything I came up with would need  
editing by others anyway.

many thanks,
david jencks

>
> Thanks,
> Toby