cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: [RT] - A Groovy Flow Engine is in my hard drive! ;-)
Date Sun, 06 Jun 2004 20:20:51 GMT
Stephan Michels dijo:
> I played yesterday with the javascript compiler around, but this didn't
> solve the problem to run rhino ontop of javaflow. So, there almost no
> advantage using the javascript compiler.

I think we can do that. Based on the experiences using Groovy (GY), I can 
said the answer is by enhancing the class loader.

In GY, I found the problem that initially I have a GY script file to be
compiled and later a true java ".class" to be loaded for BCEL when it
request the .class. The solution was in the class loader. See below.

I am thinking if will be a worth to just compile to ".class" file class
and let the loader works as expected. I think it can work similar as in
the XSP case. That way we don't need to intercept the class loader. Just
tell them where he can find more stuff to load.

Also we can also meet the autoloading requierement by creating a checking
mechanism and inform the CL that the file was changed to reload it. I am
also newbie in CL. It is just an idea. But it must work, because it works
in the XSP pages. Perhaps we need to look at XSP how it works. We have
many to learn from it. ;-)

> Another idea is to replace the root classloader by the continuation class
> loader, and instrument all rhino classes. The problem is how to configure
> the class loader. You can't use the cocoon.xconf, because you
> need already the CL for the root container.

In GY, I solved it by inserting the Groovy CL in between continuationCL
and the "given" Cl. Not sure if this is OK. As suggested, I need to move
all this stuff to scratchpad before committing. I think the CL are working
good.  I saw it working in a step-by-step basis in the eclipse debugger.

Of course, we need to refactor it. It is really really scratchpad code.
Please don't rant for his ugliness. ;-)

I want to share it, because it can give more ideas as your initial code
gave me ideas. :-D

> And using the servlet
> configuation file isn't a good idea. Then we have also a dependency to
> javaflow, which isn't any longer optional.

Nope. I think a transparent solution as above is good. I don't tested, but
I think it allow to run also javaflow code.

OK. I will start now to prepare the code for commit.

Best Regards,

Antonio Gallardo


Mime
View raw message