On 14/11/2007, at 2:03 AM, Pierre Frisch wrote:
> Anjo,
>
> I am absolutely convinced that you need to patch the base framework,
> but I want to point a couple of things:
>
> 1- There need to be a way to remove the patches for people that want
> to move on and use WO 5.4
One issue related to this is going to be when patches don't just fix
bugs, but add new functionality that is then leveraged by other code.
Unless WO baseline also includes this additional functionality, using
the same API, the patch cannot be removed without something breaking,
then a decision needs to be made whether to keep patching or drop the
patch and break backward compatibility of the other code. And
maintaining multiple versions/branches of the same patches for
different WO releases is just unmanageable for a small number of
people. (I think this comes back to your next point of how patches
should be applied).
Given that there is not likely to ever be an official way to apply
patches to com.webobjects.* classes, the only viable way that I can
see this core level patching process improving is if it's handled
intelligently at launch time rather than just hijacking classes
blindly with the classpath. Which comes back to requiring more fine
grained control of the launcher, classpath construction, class loading
and having available details about exactly what WO version is being
targeted very early in the launch phase. However this doesn't
necessarily deal with the issue I mentioned earlier of bug fixes vs
additional functionality.
The ERXPatcher approach to patching the classname resolution of
classForName() seems to work quite well, albeit not being an
officially sanctioned approach, and using private API references. But
there is nothing preventing version awareness from being added to this
patching process so that classes are not overridden unnecessarily.
> 2- I would like to see a better mechanism for patching so that we
> all know what is patched and I can work on getting those patches
> incorporated in the main line.
The patch mechanism would be somewhat dictated by how point 1 needs to
be resolved. It would be easy enough to add an audit trail to
ERXPatcher, but that only addresses half the problem. The
com.webobjects.* patching process I have been looking into, but
anything other than basic classpath ordering requires changes to the
launch process.
When you say "what is patched", do you mean which bits of code in the
class deviate from the WO code base? Or identifying which classes
have been altered/replaced in a running application?
> 3- I am working on a way to shorten Apple reaction time and that
> will reduce the need for patching
Only if you can run a version of WO that has the fixes applied.
Backporting a patch is potentially less impacting than upgrade the
whole runtime.
> 4- I am very open to rethink the bootstrap class. I would like to
> get rid of those scripts and I would like the bootstrap class to be
> able to load in a jar i.e. being able to launch a WO app by double
> clicking it and get the internal jar to load correctly. If someone
> wants to work with me on this I am more than happy to share. And yes
> adding smarted loading mechanism is a very good idea.
It is most likely that the bootstrap process for a standalone app will
still need some sort of minimal wrapper to handle passing additional
JVM arguments. To do away with the launch scripts entirely, any app
that requires non default JVM arguments would need to launch the
principalclass in a second JVM.
In the meantime can you release the source to WOBootstrap please to
facilitate some incremental improvements to the existing system.
On a related note, how does all this apply to J2EE deployments?
-- Seeya...QQuinton Dolan - qdola..mail.com Gold Coast, QLD, Australia (GMT+10) Ph: +61 419 729 806
This archive was generated by hypermail 2.0.0 : Wed Nov 14 2007 - 04:28:32 EST