Hello,
As I was pointed by a friend to the previous thread, I noticed a
proposal to prototype Brakes, which I have been working on a time ago.
This is not a commercial message, but a status report of the technology.
Brakes consists of two parts:
- A bytecode transformer adds bytecode after every method start,
and before every method call.
The bytecode before each method call makes sure the control flow of
the executing thread gets saved.
The bytecode at the start of each method checks the state of the
thread, and acts upon that (normal/saving/restoring)
- A small experimental framework which serves as a starting point for a
thread, a place in which the control flow gets saved, and the point
from which the control flow gets restored.
The research on brakes is being discontinued, partly because too few
people worked on it, partly because we (I) didn't had the nerve to get
this project into a more serious prototype stage.
The code however exists, and is usuable to certain extent.
The biggest problem is the bytecode transformer. This is a huge piece of
work by Bert Robben, a member of our research group who left four years
ago. We suspect he is the only one with full understanding about the
transformer.
A positive thing is that the transformer is based on BCEL (the bytecode
engineering library) by Markus Dahm. (During that time named JavaClass).
BCEL is still under development, now under the wings of Jakarta
http://jakarta.apache.org/bcel/
I am pretty sure that much of the 'difficult' functionality in the
transformer is now handled within the BCEL. So a rewrite of the
transformer /should/ be feasible.
The framework part is of course something that should be redesigned to
fit on Cocoon.
The past weeks, I have been looking again at BCEL, and have been
gathering ideas about how to redesign the bytecode transformer. When
you are serious about using Brakes in Cocoon, I am of course willing
to devote a great deal of time in helping with the transformer and the
framework's integration in Cocoon.
About licensing: because Brakes was abandoned so early, it is covered
under the same proprietary license as it's parent project, Correlate
http://www.cs.kuleuven.ac.be/~distrinet/projects/CORRELATE/
However, (again when you are serious about using brakes into Cocoon) it
will be possible to decouple Brakes from Correlate and embed the
subproject (Brakes) into Cocoon, or at least release it seperately under
the APL.
Oh, I am new to this list, so forgive me if I broke some rules.
Anyhow, let's hear what you think
--
Tim Coninx -*- KULeuven Department of Computer Science
http://www.cs.kuleuven.ac.be/cwis/research/distrinet/public/index.php
gpgkey @ http://www.cs.kuleuven.ac.be/~tim/
ICMP: The protocol that goes PING!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
