commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: JavaFlow: Prevent method from being instrumented
Date Tue, 05 Aug 2008 18:56:02 GMT
On Aug 4, 2008, at 01:41, Peter Niederwieser wrote:

> Thanks for the quick reply. Just wanted to go sure that excluding  
> individual
> methods is not possible as of now.

No ...not of now

> Maybe you'd be interested to hear what
> "your" software is used for:

Indeed! :)

> I'm developing a workflow engine where
> workflows are described in a Scala-based DSL and communicate with  
> remote
> services over JMS. The use of continuations has several benefits:
> - Workflows don't block a thread when waiting for messages
> - Workflows can be written in a sequential as opposed to CPS style  
> (cf.
> Scala actors)
> - Workflows can be persisted to disk so that they survive a system  
> crash
> A (simple) workflow definition currently looks like this:


That looks darn interesting.

Kohsuke did something (remotely) similar with javaflow.

In fact a couple of people mailed me in private about projects like  
But I have to say - nothing look so cool like yours ;)

> As you can imagine, class Workflow defines many more methods which  
> can be
> used from within a then-block. However, only a few of them (such as
> need to wait for a response message and therefore  
> suspend.
> Most other methods (such as succeed(), fail(), and all the synthetic  
> methods
> inserted by the Scala compiler) don't. So it would be handy to have  
> some
> control over what methods are (not) instrumented

I see

> I recently came across a post of yours where you say that quite a  
> few things
> need to be fixed before a 1.0 release of JavaFlow. Is there a document
> (JIRA?)

> describing all known problems and limitations, or could you
> (briefly) list them here?

 From the TODO:

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

> So far my research only revealed that there seems
> to be a problem with try-catch-finally.

Unfortunately there is more. But you don't alway hit them :)

In general the question is which way to go. There is the ASM  
implementation that is still very basic (and slow as I have been  
told). And there is the original BCEL implementation. But BCEL is  
really not more than in light maintenance mode. I would rather get rid  
of that dependency if possible. But that is a big change.

The testcases also need to be revisited. The current setup is terrible  

So there is quite some work to do. Frankly speaking I got a little  
annoyed that so many people use javaflow but never contribute back. So  
as I am not using it myself anymore these days - not so motivated to  
finish it up. (Although it would be nice to get a release out!)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message