On Feb 21, 2005, at 1:09 AM, Torsten Curdt wrote:
While playing with javaflow, I found out the hard way that the ContinuationClassLoader is only transforming java that is in a certain package. I made this
Sorry, about that ....of course that should be made coonfigurable.
patch to transform classes that implement Continuable and leave the others alone. This seems like the correct way to do it, but I may be missing consequences of doing it this way.
Hehe ...have a look into an older revision Just recently I've removed exactly that :)
I am not a big fan of (empty) marker interfaces. Plus this has a big impact on the behaviour of the BCEL processing.
If you do a javaClazz.getAllInterfaces() you need to have a all the depending classes and interfaces already in the internal BCEL repository.
While I did some work with ASM I found it very nice to work with ...and so I wanted get rid of a direct BCEL dependency. Which also includes accessing the repository from javaflow code other than the transformer.
BCEL tries to find and parse unknown classes by itself ...which does not really work very well in our case. ...with some effort this could of course be fixed in BCEL.
...but for now I think rewriting on the package name is quite a useable alternative that probably will fit the real world requirements.
As long it is configurable ;)
Looks like the path of least resistance. The patch I posted
earlier (the second fixed one) was a quick hack I threw together
to test the idea of passing in root packages to do transformation on.
While looking at it , I noticed that if the test case "tests" are moved into a
child package, that the entire section where the non-transformed class is
defined in the current classloader can be removed and these can be delegated to
the parent loader instead. Again at this point I may be missing something. Am I
wrong about this?
On the other hand it might be good to do a full call flow analysis so we can rewrite only those methods that might need it because we are calling suspend.
But this would required the full dependencies and is quite heavy weight on the load but more light weight on the execution. Haven't made my mind up on that yet.
WDYT?
Obviously this would be the best implementation. It seems that it would
be very heavyweight though and require a full recompilation of any dynamic
classes in order to find any calls. Also, couldn't someone get sneaky
and use reflection to call suspend (let's hope not) :-).
cheers -- Torsten
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
