Hi Andrus et.al.,
I like your new class structure, I think this might serve better going
forward.
In terms of WOStart, its a tiny piece of Code (500 lines incl comments), and
its already under a pretty generous copyright. Matter of fact I planed to
post the src on the wof-dev mailing list and also write a short article
about it on stepwise.
I attach a feature complete code drop with this email.
To start e.g. the HelloWorld app from the examples just invoke:
java -DWOUserDirectory="C:\Apple\Developer\Examples\JavaWebObjects\HelloWorl
d\HelloWorld.woa" -jar wostart.jar -WOPort 4534
No CLASSPATH is needed, no NEXT_ROOT is needed, pretty much everything is
figured out on run-time by inspecting the either the app directory or the
system file system (for next_root if needed). I tested it under NT and
solaris, and will test it also under MacOSX.
It works by the following scheme:
(+) - scan app for embedded *.jar, *.zip files
(*) - read the UNIX config file and resolve external framework references
(*) - read the UNIX config file to determine the Main class
- Construct a Classloader and init it with the set of found jar files.
- load the main class via this new classloader
- invoke main()
(+) it obviously will find any embedded frameworks :-)
(*)Removing the config files will lead to skipping of steps 2 and 3.
Since WOStart derives from URLClassLoader (:-)) and everything in the WO app
is subsequently loaded via it, I also added a little patch facility into the
game. Right now it implements only one app specific patch-directory, but
multiple directories are easy implementable (a System-wide patch dir, a user
patch dir etc.pp).
The location is *.woa/Contents/Patches and has the structure of a CLASSPATH
directory entry. Any class there will supercede classes in the jar files.
Caveat: ClassLoader does not permit patching java.* classes, there are some
limitations to what is replaceable.
So, be my guest and have a look. I am not sure how it would fit in with
woproject from a packaging perspective, as wostart is deployment and not
build focused.
I would hope that Apple Engineering will see the light and get rid of the
scripts all together and use something like my WOStart out of the box.
Right now I build a little example app, demonstrating a couple of patches
Steven Quirk gave me. He posted them also on the wo-dev list.
Regards
Reimer Mellin
-----Original Message-----
From: Andrus [mailto:andru..bjectstyle.org]
Sent: Friday, August 09, 2002 6:02 PM
To: Reimer Mellin; Juan J. Collas; Max Muller
Cc: woproject-de..bjectstyle.org
Subject: RE: Suggested changes to woproject
Hi Reimer,
I applied Juan's patch, but I think we still need a better way to organize
tasks.
At 12:00 AM 8/9/2002 -0400, Reimer Mellin wrote:
>it all depends what the long term goals are in respect to the ant support.
>Personally I am ready to totally ditch the script approach of Apple in the
>short term and migrate to war deployment in the long-term.
Me too ;-).
But as far as I am concerned, one of the WOProject goals is to be
compatible with what Apple offers, and then provide all the cool
alternatives, like the one submitted by Juan yesterday. Also I think that
there always must be a way to deploy WOApp without a container - this is
what makes it so great compared to JSP.
>So in that respect I think it makes sense to <b>reduce</b> development
>overhead in supporting the script based approach altogether and therefore I
>would 'vote' for a direct modification instead of a sub-classing approach.
>Why do you want to maintain a superclass functionality which is destined to
>die :-) ?
I agree, I think it will die. But we are already maintaining it at the
moment and will maintain it as long as there is any noticeable number of
users who need it.
Now about the ways to separate tasks. The patch submitted by Juan did not
have your WOStart included. Quoting Juan:
---------
Pure Java startup
This is based on Reimer Mellin's work to create a Java class which replaces
the scripts that currently start up the WebObjects application. This is
called WOStart, please contact ...
---------
So at the moment scripts is the only option at WOProject. Do you plan to
opensource this work as well?
Then we may organize tasks by the function performed - WOApplication
(creates app with scripts) and WOStandAlone (creates app based on WOStart),
WOWar (creates .war's). So the inheritance hierarchy can go like that:
// has all core reusable resource copying logic
abstract WOAppBase extends WOTask
// adds scripts
WOApplication extends WOAppBase
// adds embedding of frameworks
WOStandAlone extends WOAppBase
// adds web.xml and .war packaging (by internally calling War task)
WOWar extends WOStandAlone
This gives us 3 tasks with clearly defined build output.
What do you think?
Andrus
This archive was generated by hypermail 2.0.0 : Fri Aug 09 2002 - 21:57:17 EDT