geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Migrating tomcat to geronimo
Date Fri, 02 Nov 2007 17:26:30 GMT

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 [mailto:aarora@interlacesystems.com]
>> Sent: Thursday, November 01, 2007 7:51 AM
>> To: user@geronimo.apache.org
>> Subject: RE: Migrating tomcat to geronimo
>>
>>
>>
>>> -----Original Message-----
>>> From: David Jencks [mailto:david_jencks@yahoo.com]
>>> Sent: Wednesday, October 31, 2007 4:54 PM
>>> To: user@geronimo.apache.org
>>> Subject: Re: Migrating tomcat to geronimo
>>>
>>>
>>> On Oct 31, 2007, at 3:33 PM, Anil Arora wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: David Jencks [mailto:david_jencks@yahoo.com]
>>>>> Sent: Wednesday, October 31, 2007 3:41 PM
>>>>> To: user@geronimo.apache.org
>>>>> 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 catalina.properties 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
>> http://issues.apache.org/jira/browse/
>>>>>> GERONIMO
>>>>>
>>>>> 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
>>> 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
>>
>


Mime
View raw message