cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emond Papegaaij <e.papega...@student.utwente.nl>
Subject Re: Writing flowscript in Java
Date Thu, 16 Sep 2004 19:07:59 GMT
On Thursday 16 September 2004 15:19, Claudius Spellmann wrote:
> >> Is it actually possible to use Java instead of Javascript in
> >> flowscript ?
> >>
>
> Ok, but which scipting languages are implemented in cocoon ? As far as I
> can see only Javascript is available.

The javaflow block uses compiled java as a script, however I never got it to 
work the way I wanted it to work. The 'interpreter' rewrites the class file 
to basically make it an interpreter for its own bytecode. This means the 
class file will be loaded by a separate classloader that has the default 
class loader as its parent. This will prevent you from having circular 
dependencies between the flow and your business logic. For example a flow 
that calls some extra logic that will return the next flow to be started.

If you intend to only use simple flows with limited business logic and no 
dynamic class loading, it should be fine. However it was insufficient for the 
project I am working on. I also didn't want to use Javascript, because of 
it's weak type system, so I ended up writing my own 'interpreter' -- or 
better flow-engine. This engine uses compiled classes and runs a flow inside 
its own thread. This approach has several advantages but also some problems:

Advantages:
 - Exceptions are thrown to notify the flow in case of an important event 
(like a session timeout). This can also be implemented with a listener, 
however the lifecycle of a flow ends with a session timeout, so an exception 
seemed more logical.
 - It's a more 'natural' look at a flow.
 - The flow itself runs at native speed.

Disadvantages:
 - Every session will need its own thread. This can increase the load of a 
server quite a lot, allthough I haven't stressed it enough to be sure. The 
threads are locked when idle, so they should not use any cpu time.
 - It is not possible to return to a previous continuation. There is no way to 
capture the stack of a thread. You need this to restore a previous 
continuation.
 - It seems as the cocoon framework is not entirely thread safe. The session 
context seems to depend on the thread that is running. Even when the 
interpreter is locked during execution of the flow and vice versa, the 
context changes when entering the flow. I had to use reflection to make the 
interpreter thread call methods that would otherwise have been called by the 
flow itself.

Unfortunately I currently cannot release the code of this flow engine, because 
it's written for the company I work for. However this company is 
investigating open source and is planning to release (atleast parts of) the 
source under an open source license. I myself am still hoping I can 
contribute to the Cocoon project by making this flow engine available. If you 
can't wait for this, you can check the current implementations of the 
Interpreter interface. Currently there are several implementations: 
FOM_JavaScriptInterpreter, CompilingInterpreter, ApplesProcessor, 
AO_FOM_JavaScriptInterpreter, JavaInterpreter

Good luck,
Emond Papegaaij

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message