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 Fri, 02 Nov 2007 22:17:19 GMT

On Nov 2, 2007, at 3:05 PM, Anil Arora wrote:

> the part about creating my own shared lib is what then I  
> need to
> work on next.  I'll worry about the other pieces to start the server
> without deployment later.  At this point, it's all one big exercise to
> see if its feasible.
> To create my own shared lib, are you talking about writing code or  
> is it
> as simple as making configuration file changes?

If you are using a pre-2.1 geronimo version, deploy a plan like this,  
modified to use your directory locations in the gbean and include the  
jasper dependency either from the jar or the jasper configuration:

<?xml version="1.0" encoding="UTF-8"?>
<!--Licensed to the Apache Software Foundation (ASF) under one or more
     contributor license agreements.  See the NOTICE file distributed  
     this work for additional information regarding copyright ownership.
     The ASF licenses this file to You under the Apache License,  
Version 2.0
     (the "License"); you may not use this file except in compliance  
     the License.  You may obtain a copy of the License at

     Unless required by applicable law or agreed to in writing, software
     distributed under the License is distributed on an "AS IS" BASIS,
     See the License for the specific language governing permissions and
     limitations under the License.-->
<!--$Rev: 589946 $ $Date: 2007-10-29 19:53:25 -0700 (Mon, 29 Oct  
2007) $-->
<module xmlns="">
   <!--The SharedLib Service-->
   <gbean name="SharedLib"  
     <attribute name="classesDirs">var/shared/classes</attribute>
     <attribute name="libDirs">var/shared/lib</attribute>
     <reference name="ServerInfo">

If you are using 2.1 you can copy the applications/sharedlib module,  
modify the artifact id and the plan, and build it with maven to get a  
geronimo plugin that you can install into the server.

Hope this helps
david jencks

> Anil
>> -----Original Message-----
>> From: David Jencks []
>> Sent: Friday, November 02, 2007 11:27 AM
>> To:
>> Subject: Re: Migrating tomcat to geronimo
>> On Nov 2, 2007, at 9:11 AM, Anil Arora wrote:
>>> David, you said that 2.1 would make this mechanism easier.  Well, I
>>> got
>>> a hold of a 2.1 binary.  How would this be easier?
>> The part that's easier is constructing a custom server with only the
>> stuff you need to support your app.  Getting your app to run is about
>> the same process.  Right now to get a custom server you need to use
>> maven to build your configurations and assemble the server but we
>> will probably have a way to do it from a running server in a few  
>> days.
>>  From what you've described so far, and assuming I can't convince you
>> that putting your jars in the geronimo repo is really the simplest
>> solution, I think your best bet is to deploy your own shared lib
>> configuration where you can specify the parents such as jasper, and
>> then use this as a parent for your app itself.
>> Geronimo classloaders allow you very fine control over exactly what
>> class is visible where, but you do have to conform to a few
>> conditions to use them, mostly that you organize your jars into  the
>> repository structure.  Trying to do something else such as using a
>> shared lib directory that gives you little control over classloader
>> structure doesn't work as well as using the dependency system.  On
>> the other hand even the shared-lib gbean gives you more possibilities
>> than tomcat's shared-lib since you can get the jars into the
>> application classloader rather than into a parent classloader.  The
>> restriction is that these classes aren't available at deployment,
>> just when the app is running.  With a separate shared lib
>> configuration that you can start before deploying your app the
>> classes will be available for your application deployment.
>> hope this helps
>> david jencks
>>> Anil
>>>> -----Original Message-----
>>>> From: Anil Arora []
>>>> Sent: Thursday, November 01, 2007 7:51 AM
>>>> To:
>>>> Subject: RE: Migrating tomcat to geronimo
>>>>> -----Original Message-----
>>>>> From: David Jencks []
>>>>> Sent: Wednesday, October 31, 2007 4:54 PM
>>>>> To:
>>>>> Subject: Re: Migrating tomcat to geronimo
>>>>> 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
>>>>>>>>> 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
> own
>>>>>>>>> jars in the classpath.  I do all of this to avoid the
>>> step
>>>>>>>>> of deploying that application.
>>>>>>>>> So, question is whether or not I can do similar things
>>>>>>>>> Geronimo.  Given the location of the Geronimo installation,
>>>> just
>>>>>>>>> want to write a script that starts the server and have
>>> already
>>>>>>>>> know my extra jar files and the location of my webapp
>>>>>>>>> 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
>>>>>>>> discussion about adding this type of feature so that
>>> applications
>>>>>>>> can be run from within an Eclipse workspace directory, but
>>> don't
>>>>>>>> think that anything usable has taken shape yet.   Feel free
>>>> open
>>>>>>>> a feature request for this at
>>>>>>>> GERONIMO
>>>>>>> Maybe I'm misinterpreting what Anil is requesting, but it looked
>>> to
>>>>>>> me as if he might be interested in deploying his application
> 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
>>>> 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
>>>>> load="false")
>>>>> 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
>>>> Wow, this is great information.  Yeah, I'm not too worried about
>>> people
>>>> hacking the config file if they need to later.
>>>> The other thing I need to make sure that works without hardcoding
> the
>>>> root directory.  If I deployed the application, does the directory
>>>> get
>>>> hardcoded in the internal database?
>>>> For the shared lib bean, I've been trying to figure out to get
>>>> this to
>>>> work.  I made the following change in my config.xml to test this
> out.
>>>>     <module name="org.apache.geronimo.configs/sharedlib/2.0.2/car">
>>>>         <gbean name="SharedLib">
>>>>             <attribute
>>> name="classesDirs">c:/dev/main/install,c:/dev/main/install/internal/
>>> inte
>>>> rlace/bundles,c:/dev/main/install/interlace/bundles</attribute>
>>>>             <attribute
>>> name="libDirs">c:/dev/main/install/internal/lib,c:/dev/main/install/
>>> lib<
>>>> /attribute>
>>>>         </gbean>
>>>>     </module>
>>>> However, it does not seem to be picking up classes from any
> specified
>>>> lib directories.
>>>> I also tried sticking this in my Geronimo-web.xml file as well.
>>>> Is there a date for the 2.1 version to come out?
>>>> Anil

View raw message