Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 62855 invoked from network); 2 Nov 2007 22:18:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Nov 2007 22:18:04 -0000 Received: (qmail 42830 invoked by uid 500); 2 Nov 2007 22:17:50 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 42810 invoked by uid 500); 2 Nov 2007 22:17:50 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 42799 invoked by uid 99); 2 Nov 2007 22:17:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2007 15:17:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [69.147.95.76] (HELO smtp113.plus.mail.sp1.yahoo.com) (69.147.95.76) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 02 Nov 2007 22:18:12 +0000 Received: (qmail 45735 invoked from network); 2 Nov 2007 22:17:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=SCbwpP6Q105fcUILYNRoVXiMdFmoPbRJbpfbLEYdBLQBnmqO12XCrcGss4vZ+mLPOjsL8+sv2SGFr92mT4IgUGClxsry1rjMQ1lcDgYmP64dhp1/Ed7MnDt+ILyPgBijpZLqGDJLRksVQl/4M8TDoGQxoo9Eji2FCFuJIZQpfQ0= ; Received: from unknown (HELO ?192.168.1.101?) (david_jencks@67.102.173.8 with plain) by smtp113.plus.mail.sp1.yahoo.com with SMTP; 2 Nov 2007 22:17:29 -0000 X-YMail-OSG: wyHEtE4VM1n7yZB6hSLbkggAVd32XSn6lNpzC5it4O0ecPaTKA3Ap5nqzf0JFYkYMXueK6h4lFow93IYWe39Lw32NUUlh9YIJnM2lboM_..G82QO3rrwOx1Xyz_X Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <24039A7138B8FB4480B76DB3B939ACEE7CC8A3@hqfs1.interlacesystems.com> References: <24039A7138B8FB4480B76DB3B939ACEE7CC8A3@hqfs1.interlacesystems.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: Migrating tomcat to geronimo Date: Fri, 2 Nov 2007 15:17:19 -0700 To: user@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org 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: org.apache.geronimo.configs sharedlib 2.1-SNAPSHOT car org.apache.geronimo.configs rmi-naming 2.1-SNAPSHOT car var/shared/classes var/shared/lib 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 [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. >>>> >>>> >>>> >>>> >>> >>> name="classesDirs">c:/dev/main/install,c:/dev/main/install/internal/ >>> inte >>>> rlace/bundles,c:/dev/main/install/interlace/bundles >>>> >>> >>> name="libDirs">c:/dev/main/install/internal/lib,c:/dev/main/install/ >>> lib< >>>> /attribute> >>>> >>>> >>>> >>>> >>>> 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 >>>> >>> >