Le 2011-03-13 à 19:01, Aurélien Minet a écrit : > Hi Pascal > > I hope it's not too late for responding > > On 02/23/2011 12:58 PM, Pascal Robert wrote: >> I'm looking at how I will distribute the product I'm working on, and so that >> the WO backend can be easily installed by a semi-pro who doesn't have >> intimate knowledge of the command line or Apache configuration file. > so out of the box deployment is need : downloading the package, launching > the setup and input a few parameters , right ?
I targeting not having to input parameters except a admin password, but yes it's for a download/install type of product. > does a graphical interface is available on the server where the product will > be installed ? a wizzard like in woinstaller could help. No GUI is preferred. I always disable GUI on my CentOS Linux servers and I know I'm not the only one doing this :-) >> So I was thinking of distributing the app with it's own version of Apache >> with the WO Apache module, the app, and wotaskd, and include everything in a >> .pkg or .rpm. > Package based on .pkg .rpm ... are depending of the OS so you have to > target an OS: OS X 10.?, Linux distribution and an arch (x86_32/_64), > multiple package may be needed to match each environment/OS. I'm aware of this, and I know it can become a nightware (.pkg for OS X, .deb for Ubuntu/Debian, .rpm for CentOS/RH/SuSE). For now, I'm only targeting OS X (10.5+) and CentOS (4.0+). > A wizard will have to manage several case depending of the OS version, > updates, arch . > >> Why including wotaskd? Because I want some kind of watch guard to restart >> instances in case they crash, auto restart if the server is restarted, etc. > Launchd can do that on OS X, under Linux there is old tools like inetd/xinetd > or newer like upstart. > > globally under UNIX there is the old javawoservice.sh, it can be reworked to > build/rebuild on demand a WOConfig.xml file (which mod_WebObjects will > read), then wotaskd isn't needed > (if there is only one-application with few instance the WOConfig.xml file > would be simple to produce) I agree, and yes the product by default would only have one application and one instance by default. Adding instances would be a automatic thing, eg writing something to watch the load/memory usage of current instances, and if more instances are needed, launch a new one automatically. >> Now why I'm not including JavaMonitor? That's simple: I want to reduce >> memory footprint and JavaMonitor always eat at least 32 MB of RAM, and since >> a lot of people are using VPS or Amazon EC2 for their servers and have >> somewhat limited RAM resources. > In fact for me JavaMonitor is the "one ring to rule them all": wotaskds are > just slaves: they have to apply the configuration (SiteConfig.xml) and > deployment is just file and process management. > In your case if the configuration is almost fixed: all the application > configuration is set and instances are defined. The only things left to setup > are: > _ how many instances > _ the optional scheduling (auto-restart could be pre-configured with cron) > > as explained, if low memory footprint is the target and if the configuration > is static I would not include/use wotaskd but some shell scripts somewhat > like javawoservice.sh > >> So what I was thinking about is to move the REST routes I added to >> JavaMonitor down into wotaskd. By doing that I would be able to create a >> small HTML page with JavaScript to talk to wotaskd and ask for stats, status >> of instances, etc. By doing so, I need to do some refactoring since some >> code will have to go from JavaMonitor and JavaMonitorFramework to wotaskd. > WOAdaptorInfo in mod_WebObjects would provide the entry point for an > application running on the client-side as it will list all available > instances. In turn each instances would provide, through REST services, > theirs own statistics. > With this kind of remote monitoring there'll have no extra stuff eating RAM > on the server. >> Any opinions? > > Maybe an "appliance" provided under a .vdi file (compatible with VMWare, > Virtualbox ...) would be a generic solution, with inside a Linux with > everything configured (except network stuff IP/GW/DNS but DHCP can take care > of that). A semi-pro can import the disk file and setup a VM ? That's the plan too. CentOS VM with everything needed on it, and asking basic questions (root password, network setup) when the VM fired off the first time. > (There is also the problem of the database if any, embedded or not) Planning to use H2. The database size will be quite low, because it will only contains user accounts (the product is a bridge between CalDAV servers and a new calendar/tasks client I'm working on). > Another option could be a Tomcat bundle, but adding it to system services and > Apache configuration still be need. It's an option, but I don't know how it would work for load, if the app is overloaded or heap usage is reaching its limit, how can I start another "instance"? > There is not an easy solution, it depends on what the semi-pro can do. > > Aurélien > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-deploy/probert%40macti.ca > > This email sent to prob...@macti.ca _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com This email sent to arch...@mail-archive.com