You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Anil Arora <aa...@interlacesystems.com> on 2007/11/01 14:51:21 UTC

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



Re: Migrating tomcat to geronimo

Posted by David Jencks <da...@yahoo.com>.
On Nov 2, 2007, at 3:05 PM, Anil Arora wrote:

> Ok...so 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  
with
     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  
with
     the License.  You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

     Unless required by applicable law or agreed to in writing, software
     distributed under the License is distributed on an "AS IS" BASIS,
     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or  
implied.
     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="http://geronimo.apache.org/xml/ns/deployment-1.2">
   <!--The SharedLib Service-->
   <environment>
     <moduleId>
       <groupId>org.apache.geronimo.configs</groupId>
       <artifactId>sharedlib</artifactId>
       <version>2.1-SNAPSHOT</version>
       <type>car</type>
     </moduleId>
     <dependencies>
       <dependency>
         <groupId>org.apache.geronimo.configs</groupId>
         <artifactId>rmi-naming</artifactId>
         <version>2.1-SNAPSHOT</version>
         <type>car</type>
       </dependency>
     </dependencies>
     <hidden-classes/>
     <non-overridable-classes/>
   </environment>
   <gbean name="SharedLib"  
class="org.apache.geronimo.system.sharedlib.SharedLib">
     <attribute name="classesDirs">var/shared/classes</attribute>
     <attribute name="libDirs">var/shared/lib</attribute>
     <reference name="ServerInfo">
       <name>ServerInfo</name>
     </reference>
   </gbean>

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 [mailto:david_jencks@yahoo.com]
>> Sent: Friday, November 02, 2007 11:27 AM
>> To: user@geronimo.apache.org
>> 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 [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
>>>>
>>>
>


RE: Migrating tomcat to geronimo

Posted by Anil Arora <aa...@interlacesystems.com>.
Ok...so 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?  

Anil


> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Friday, November 02, 2007 11:27 AM
> To: user@geronimo.apache.org
> 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 [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
> >>
> >


Re: Migrating tomcat to geronimo

Posted by David Jencks <da...@yahoo.com>.
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
>>
>


RE: Migrating tomcat to geronimo

Posted by Anil Arora <aa...@interlacesystems.com>.
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?

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
>