geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Migrating tomcat to geronimo
Date Wed, 31 Oct 2007 22:53:57 GMT

On Oct 31, 2007, at 3:33 PM, Anil Arora wrote:

>> -----Original Message-----
>> From: David Jencks []
>> Sent: Wednesday, October 31, 2007 3:41 PM
>> To:
>> Subject: Re: Migrating tomcat to geronimo
>> On Oct 31, 2007, at 9:57 AM, Paul McMahan wrote:
>>> On Oct 31, 2007, at 12:16 PM, Anil Arora wrote:
>>>> I'm doing an experiment porting our application to Geronimo from
>>>> Tomcat.  I am having a few difficulties with some of the
>>>> customization features which I need to also port.
>>>> For Tomcat, I have a custom server.xml file, in which I turn off
>>>> hot deployment and hardcode the location of my webapplication.  I
>>>> also have a custom where I can stick my own
>>>> jars in the classpath.  I do all of this to avoid the extra step
>>>> of deploying that application.
>>>> So, question is whether or not I can do similar things with
>>>> Geronimo.  Given the location of the Geronimo installation, I just
>>>> want to write a script that starts the server and have it already
>>>> know my extra jar files and the location of my webapp without
>>>> having to execute the deploy tool.
>>>> Can this be done?
>>> I don't know of any way to bypass the deployment process for an
>>> application in Geronimo.  You can use Geronimo's hot deployment
>>> feature to avoid some of the manual steps involved in deployment,
>>> but you said that you actually turned that feature off in Tomcat so
>>> I assume it's not an acceptable solution.  There has been some
>>> discussion about adding this type of feature so that applications
>>> can be run from within an Eclipse workspace directory, but I don't
>>> think that anything usable has taken shape yet.   Feel free to open
>>> a feature request for this at
>> Maybe I'm misinterpreting what Anil is requesting, but it looked to
>> me as if he might be interested in deploying his application as a
>> plugin, or just deploying it once and having it in the server, and
>> that he is looking for some of the features we actually support.
>> You can include any jars you want scoped to your application
>> classloader by putting them in appropriate locations in the geronimo
>> repo and including dependencies on them in the geronimo plan for your
>> app.
>> Are you trying to construct a server with your app already deployed
>> that you can distribute so that users can unpack and start and your
>> app will be running but they can't deploy more apps?  That is really
>> easy to do in trunk and only slightly harder in released geronimo
>> versions.  Basically you would turn your app into a plugin and use it
>> to construct a custom server than has only the geronimo components
>> needed to support the app.  If this is what you are aiming for let us
>> know and tell us which geronimo version(s) you can use and we can
>> give you more instructions.
>> thanks
>> david jencks
>>> Best wishes,
>>> Paul
> Yes, this is probably a better way of saying what I want to do.  In  
> the
> end, I do want to have something prebuilt that the users can just run.
> There's no need to deploy anything else on the server.  I was  
> hoping to
> avoid extra coding, but I'm willing to look into this.

So far I don't see why you would have to write any extra code.
> Is there a way to have a custom classloader that doesn't use this plan
> mechanism?  If I'm going to build custom code, I'd might as well write
> this.  This would help me avoid moving lib files around.  One  
> problem is
> that these libraries are used for other command line scripts.

If I understand correctly you want the additional libraries to be in  
a particular location rather than putting them in the geronimo  
repository?  We supply a shared-lib configuration that lets you add  
all the jars in a directory into that configurations classloader, so  
you might just include that as a parent of your app in the geronimo  
plan.  Otherwise you can include a SharedLib gbean in  your  
applications plan directly and the jars will be in the same  
classloader as the rest of your app.
> I would like to stick with a released version for stability  
> reasons.  I
> currently have 2.0.

I recommend you do the following; it may result in a slightly larger  
server than you need but is quite a bit simpler on pre-2.1 than the  
alternatives to get the smallest possible server.

1. start with one of the minimal geronimo servers (unless you want  
e.g. the admin console, in which case you need one of the full  
servers or 2.1 :-)
2. deploy your app on the server.
3. edit var/config/config.xml and remove any modules whose name ends  
in -deployer (such as tomcat-deployer) (or add an attribute  
4. remove any extraneaous logs from var/log
5 zip up what's left and distribute it

If all goes well your users will get something they can unzip and run  
with no further configuration but they won't be able to deploy any  
more apps on it.  (If they know enough about geronimo they could re- 
enable the deployers, but you can't really protect against stuff like  
that; with tomcat they could re-enable the hot deploy directory).

hope this helps!
david jencks

> Thanks,
> Anil

View raw message