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 ?
does a graphical interface is available on the server where the product will be installed ? a wizzard like in
woinstaller could help.
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.
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)
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 ?
(There is also the problem of the database if any, embedded or not)
Another option could be a Tomcat bundle, but adding it to system services and
Apache configuration still be need.
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
