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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > 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:[EMAIL PROTECTED] > > >> 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 >
