You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Kohsuke Kawaguchi <kk...@kohsuke.org> on 2005/08/25 08:39:59 UTC

[javaflow] debug code

Torsten,

I made a few changes so that debug code doesn't run by default (I don't 
think applications want to see the class file dumps in the current 
directory!) I hope this change is OK with you.

I have a few other debug code related issues.

The first one is easy one. I saw that javaflow.jar ships with 
simplelog.properties, which configures the logger to print the debug 
messages. Shouldn't this file be moved to the src/test?

Second, because of the way javaflow instruments 'new' instruction, every 
constructor argument goes through a Stack object.

So when the code is like:

void foo() {
   InputStream is = new BufferedInputStream(new FileInputStream(...));
   ...
   is.close();
   is = null;

   Continuation.suspend();
}

I still get a warning saying "FileInputStream is not serializable" when 
the first line is executed (not when the execution suspends.) When we 
are capturing the stack, this warning message could be useful 
(especially because it can point to a specific stack frame), but this 
false positive isn't desirable. Also, there are perfectly good use cases 
  of javaflow that doesn't involve in serialization.

So I'm wondering what to do with this.

One idea that occurred to me is that when we see a non-serializable 
object pushed into a stack, we just create an exception without throwing it.

Later in the writeObject method, if a non-serializable object is going 
to be serialized, we can use this exception to tell users where this 
object was captured.

Or you might think it's a non-issue (in the sense that users can just 
turn off the logging to get rid of the warnings.)


The trouble I have in the workflow engine is that I want to ship it with 
logging turned off by default (because of those false-positives), but 
when there's actually a problem, I want to provide a meaningful errors 
right away. Telling them to manually turn on the logging won't be a very 
good user experience.

-- 
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [javaflow] debug code

Posted by Torsten Curdt <tc...@apache.org>.
> I made a few changes so that debug code doesn't run by default (I  
> don't think applications want to see the class file dumps in the  
> current directory!) I hope this change is OK with you.

Hehe :) Sure

> I have a few other debug code related issues.
>
> The first one is easy one. I saw that javaflow.jar ships with  
> simplelog.properties, which configures the logger to print the  
> debug messages. Shouldn't this file be moved to the src/test?

Well, would probably be good enough.

> Second, because of the way javaflow instruments 'new' instruction,  
> every constructor argument goes through a Stack object.

<snip/>

> I still get a warning saying "FileInputStream is not serializable"  
> when the first line is executed (not when the execution suspends.)

<snip/>

> So I'm wondering what to do with this.
>
> One idea that occurred to me is that when we see a non-serializable  
> object pushed into a stack, we just create an exception without  
> throwing it.

TBH ...that's one of the things were
I wasn't sure either. Actually what
I was thinking is that it would be
much better to provide an API where
you can register a listener so you
get notified about the non-serializable
objects.

WDYT?

> The trouble I have in the workflow engine is that I want to ship it  
> with logging turned off by default (because of those false- 
> positives), but when there's actually a problem, I want to provide  
> a meaningful errors right away. Telling them to manually turn on  
> the logging won't be a very good user experience.

Sure

cheers
--
Torsten (who is still working through a 3 weeks backlog of emails)