Hey Torsten!
Hey Gabriel
I have been watching the mailinglist for the last year or so to see
changes in javaflow in 2.2 which I would love to use.
There weren't many ;)
It seems that you are the only one with the "complete" knowledge to
finish javaflow in 2.2... I am sure there are others around which
would like to help to get the job done. but my feeling so far is
that it would be only minimum effort for you compared to all the
others who have given up so far on this job...
Indeed as one of the main authors of javaflow and being a cocoon old
timer ...that could be right :)
another option would be if you could lay out your plan for
implementation and some other interested comitters could do it?
I surely can try.
WDYT?
I would love to use javaflow and i would love to help too if i can...
What needs to be done can be split into 3 parts
1. The Cocoon side of things
1.1 Last time I checked the continuation management infrastructure in
Cocoon needs an overhaul. While the recent thread on javaflow
scalability was 2.1 I am sure this still holds true for 2.2. I has
been a few years so please bear with my memory ...but I think the
following problems need to be addressed:
1.1.1 WebContinuation is a class but should be an interface. Javaflow
and flowscript would be a possible implentation.
1.1.2 Just like sessions there needs to be a hard limit for the number
of continuations that is enforced on continuation creation time
1.2 IIRC there currently is only one script allowed per sitemap. There
is no real good reason for that.
1.3 Support for flows in sub pipelines. This is more a special case
that mainly needs to addressed in javaflow - not i Cocoon land. But
it's a special case that has come up only in Cocoon. Javaflow
currently uses thread locals to store information. Maybe it would be
better to store that information in a context ...another option to
look into would be to use a stack. I'd prefer the context approach
though.
2. Javaflow over in commons
2.1 Javaflow currently has two implementations. The original one is
BCEL. The new one is ASM. It would be great to switch to ASM for
various reasons. But it seems the ASM implementation is even less
robust than the current BCEL one. Still I think is essential to focus
on just the one. And surely ASM is the way to go. That would also make
the current weird testcase approach simpler in javaflow.
2.2 There are a couple of byte code level things that need to be
fixed. This surely is the trickiest part.
o fix unintialized objects for method/constructor calls
o inner classes
o try/catch/finally
o synchronized(obj)
o accessing .class
o new Object() without assignment
see
http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/TODO?revision=560660&view=markup
There was some discussion in joining forces with Geer from RIFE. The
RIFE continuations work a little bit differently though and impose
some restrictions onto how you need to write the flow. Plus it's
LGPL ....but Geer sounded flexible about that when we talked. We also
tried to start a JSR for continuation support in the JVM - but that
was shut down. (Even Apache - whoever was responsible for it - voted
for "no")
2.3 Continuation branching should be re-evaluated. Cloning?
Serialization?
3. Build integration
3.1 Writing a maven plugin to instrument the resulting artifact should
probably just a few hours job. The initial goal was to replace the
maven compiler plugin with a maven jci plugin but... can't hurt to be
a bit more pragmatic on that one. I don't see maven really adopting
JCI for that anytime soon.
...that's how I remember it at least :)
Of course documentation is needed. And I also expect that the examples
need some love. I bet there is more :)
Unfortunately I don't really have the time and enthusiasm working on
this at the moment. Would be great to get this finished up and
released though. If someone else has the time and motivation - I am
certainly happy to give comments/advice.
cheers
--
Torsten
