Extracting continuations

[Patrick Lightbody-3]

In a previous email exchange with Geert, I mentioned that I wanted to  
help extract RIFE's continuation support and introduce it to WebWork.  
I think that RIFE in general is a very excellent application  
framework (not just a web development framework) and am especially  
pleased with the continuation support.

As such, I was hoping Geert could give me a starting point on how to  
extract the continuation stuff. Once I get it working, I'll  
definitely be donating the extracted package back to RIFE or would be  
happy to include it in an existing project (such as OSCore, for  
example) if that is easiest.

Patrick

[Geert Bevin]

Hi Patrick,

thanks for the nice comments (again ;-))!

I would prefer it to be a separate project under the RIFE brand, for  
example RIFE/continuations. Like this it keeps our investment related  
to the framework and it might give the whole project more credibility  
when it's used by others.

First, the licensing issue. Currently RIFE is LGPL, but I'm thinking  
about dual-licensing it under the CDDL too. I hope that's ok for you.

Now for the technical part.

The continuations are based on on-the-fly byte-code modification  
through a dedicated classloader. We use ASM for the byte-code  
handling and have included it inside RIFE since we wanted to keep it  
one jar and ASM is small anyway. It also solved possible version  
incompatibilities with previous ASM versions and makes sure that the  
classes are not loaded by another classloader thanks to its unique  
package (com.uwyn.rife.asm).

Now for the structure and design.

Everything starts at com.uwyn.rife.engine.EngineClassLoader. Note  
that JDK 1.5 syntax features are used and that I'd like it to remain  
like that for code clarity. Using codeguide's compiler or Retroweaver  
makes this easily byte-code compatible with JDK 1.4 (which is what we  
do for the whole of RIFE anyway). The previous guy that worked on  
extracting the continuations engine just worked from there onwards  
and added all the classes that were required. The continuations  
engine is totally encapsulated and should use none of the other  
framework classes to prevent duplicate class definition exceptions  
and the like.

Currently, the bytecode is only inspected if the class is considered  
part of the web application. This is done through checks for WEB-INF  
in the resource path, through checks for the com.uwyn.rife. package  
(the RIFE jar is supposed to be part of every web application and not  
a global jar), and through manual configuration with the  
rife.webapp.path system property. After that the classloader  
determines if the class is an Element (ElementDetectionClassVisitor).  
 From that point onwards, the classloader will analyze the bytes of  
the class in detail and check for the presence of pause() and String  
call(Object) method calls on an ElementSupport instance  
(MetricsMethodVisitor). When this analysis detects that continuations  
are used, the actual byte-code modification is performed.

I suppose that the 'Element' notion should be abstracted and that the  
package name should be configurable somewhere in the extracted API  
(probably when the continuation engine is registered or integrated).

I hope this provides enough information to get you started, just let  
me know here if something isn't clear.

Best regards,

Geert

On 15-sep-05, at 13:13, Patrick Lightbody wrote:

> In a previous email exchange with Geert, I mentioned that I wanted  
> to help extract RIFE's continuation support and introduce it to  
> WebWork. I think that RIFE in general is a very excellent  
> application framework (not just a web development framework) and am  
> especially pleased with the continuation support.
>
> As such, I was hoping Geert could give me a starting point on how  
> to extract the continuation stuff. Once I get it working, I'll  
> definitely be donating the extracted package back to RIFE or would  
> be happy to include it in an existing project (such as OSCore, for  
> example) if that is easiest.
>
> Patrick
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://www.uwyn.com/mailman/listinfo/rife-devel
>
>

--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net

[Patrick Lightbody-3]

> I would prefer it to be a separate project under the RIFE brand,  
> for example RIFE/continuations. Like this it keeps our investment  
> related to the framework and it might give the whole project more  
> credibility when it's used by others.
>

Sounds fair enough - I just offered as I wasn't sure how much  
availability you had to start a new project (that always takes some  
time, setting up infrastructure, etc).

> First, the licensing issue. Currently RIFE is LGPL, but I'm  
> thinking about dual-licensing it under the CDDL too. I hope that's  
> ok for you.

What is CDDL? OpenSymphony is effectively Apache, but since we'd just  
be using it (and not modifying it), I see no problem with any  
license. Is that right?

> Now for the technical part.
>
> The continuations are based on on-the-fly byte-code modification  
> through a dedicated classloader. We use ASM for the byte-code  
> handling and have included it inside RIFE since we wanted to keep  
> it one jar and ASM is small anyway. It also solved possible version  
> incompatibilities with previous ASM versions and makes sure that  
> the classes are not loaded by another classloader thanks to its  
> unique package (com.uwyn.rife.asm).
>
> Now for the structure and design.
>
> Everything starts at com.uwyn.rife.engine.EngineClassLoader. Note  
> that JDK 1.5 syntax features are used and that I'd like it to  
> remain like that for code clarity. Using codeguide's compiler or  
> Retroweaver makes this easily byte-code compatible with JDK 1.4  
> (which is what we do for the whole of RIFE anyway). The previous  
> guy that worked on extracting the continuations engine just worked  
> from there onwards and added all the classes that were required.  
> The continuations engine is totally encapsulated and should use  
> none of the other framework classes to prevent duplicate class  
> definition exceptions and the like.
>
> Currently, the bytecode is only inspected if the class is  
> considered part of the web application. This is done through checks  
> for WEB-INF in the resource path, through checks for the  
> com.uwyn.rife. package (the RIFE jar is supposed to be part of  
> every web application and not a global jar), and through manual  
> configuration with the rife.webapp.path system property. After that  
> the classloader determines if the class is an Element  
> (ElementDetectionClassVisitor). From that point onwards, the  
> classloader will analyze the bytes of the class in detail and check  
> for the presence of pause() and String call(Object) method calls on  
> an ElementSupport instance (MetricsMethodVisitor). When this  
> analysis detects that continuations are used, the actual byte-code  
> modification is performed.
>
> I suppose that the 'Element' notion should be abstracted and that  
> the package name should be configurable somewhere in the extracted  
> API (probably when the continuation engine is registered or  
> integrated).
>
> I hope this provides enough information to get you started, just  
> let me know here if something isn't clear.
>

This should be enough, though I'd like to avoid requiring JDK 1.5.  
WebWork actually works on 1.3 even, though we should probably bump  
that up to 1.4 soon. Retroweaver is an option, though I don't know  
much about it. Provided it is easy to integrate in a build, I'm happy  
to use it.

Anyway, I'll get started. Thanks for the help.

> Best regards,
>
> Geert
>
> On 15-sep-05, at 13:13, Patrick Lightbody wrote:
>
>
>> In a previous email exchange with Geert, I mentioned that I wanted  
>> to help extract RIFE's continuation support and introduce it to  
>> WebWork. I think that RIFE in general is a very excellent  
>> application framework (not just a web development framework) and  
>> am especially pleased with the continuation support.
>>
>> As such, I was hoping Geert could give me a starting point on how  
>> to extract the continuation stuff. Once I get it working, I'll  
>> definitely be donating the extracted package back to RIFE or would  
>> be happy to include it in an existing project (such as OSCore, for  
>> example) if that is easiest.
>>
>> Patrick
>>
>> _______________________________________________
>> Rife-devel mailing list
>> Rife-devel@...
>> http://www.uwyn.com/mailman/listinfo/rife-devel
>>
>>
>>
>
> --
> Geert Bevin                       Uwyn bvba
> "Use what you need"               Avenue de Scailmont 34
> http://www.uwyn.com               7170 Manage, Belgium
> gbevin[remove] at uwyn dot com    Tel [phone]
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://www.uwyn.com/mailman/listinfo/rife-devel
>

[Geert Bevin]

> Sounds fair enough - I just offered as I wasn't sure how much  
> availability you had to start a new project (that always takes some  
> time, setting up infrastructure, etc).

That will be ok, I'm getting quite experienced at that ;-)

I can setup a Subversion repository for you if you want, just mail me  
in private a username and a password. As soon as some code has been  
there, I'll create a Jira and Confluence space too.

>> First, the licensing issue. Currently RIFE is LGPL, but I'm  
>> thinking about dual-licensing it under the CDDL too. I hope that's  
>> ok for you.
>>
>
> What is CDDL? OpenSymphony is effectively Apache, but since we'd  
> just be using it (and not modifying it), I see no problem with any  
> license. Is that right?

CDDL is a modified MPL license adapted by Sun specifically for  
commercially friendly copyleft Java libraries. It's soon even going  
to get the blessing for Apache itself. There is no compatibility  
problem with the apache license.

> This should be enough, though I'd like to avoid requiring JDK 1.5.  
> WebWork actually works on 1.3 even, though we should probably bump  
> that up to 1.4 soon. Retroweaver is an option, though I don't know  
> much about it. Provided it is easy to integrate in a build, I'm  
> happy to use it.

Retroweaver can be run just like any ant task, it's totally  
transparent besides a very small additional runtime jar that provides  
some compatibility classes. If you have problems getting it to work,  
JR Boyens (the other RIFE lead) is very proficient with it.

> Anyway, I'll get started. Thanks for the help.

Anytime, just ask when something is not clear.


--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net

[Patrick Lightbody-3]

One question: where is the source repo? :)

On Sep 15, 2005, at 2:01 PM, Geert Bevin wrote:

> Hi Patrick,
>
> thanks for the nice comments (again ;-))!
>
> I would prefer it to be a separate project under the RIFE brand,  
> for example RIFE/continuations. Like this it keeps our investment  
> related to the framework and it might give the whole project more  
> credibility when it's used by others.
>
> First, the licensing issue. Currently RIFE is LGPL, but I'm  
> thinking about dual-licensing it under the CDDL too. I hope that's  
> ok for you.
>
> Now for the technical part.
>
> The continuations are based on on-the-fly byte-code modification  
> through a dedicated classloader. We use ASM for the byte-code  
> handling and have included it inside RIFE since we wanted to keep  
> it one jar and ASM is small anyway. It also solved possible version  
> incompatibilities with previous ASM versions and makes sure that  
> the classes are not loaded by another classloader thanks to its  
> unique package (com.uwyn.rife.asm).
>
> Now for the structure and design.
>
> Everything starts at com.uwyn.rife.engine.EngineClassLoader. Note  
> that JDK 1.5 syntax features are used and that I'd like it to  
> remain like that for code clarity. Using codeguide's compiler or  
> Retroweaver makes this easily byte-code compatible with JDK 1.4  
> (which is what we do for the whole of RIFE anyway). The previous  
> guy that worked on extracting the continuations engine just worked  
> from there onwards and added all the classes that were required.  
> The continuations engine is totally encapsulated and should use  
> none of the other framework classes to prevent duplicate class  
> definition exceptions and the like.
>
> Currently, the bytecode is only inspected if the class is  
> considered part of the web application. This is done through checks  
> for WEB-INF in the resource path, through checks for the  
> com.uwyn.rife. package (the RIFE jar is supposed to be part of  
> every web application and not a global jar), and through manual  
> configuration with the rife.webapp.path system property. After that  
> the classloader determines if the class is an Element  
> (ElementDetectionClassVisitor). From that point onwards, the  
> classloader will analyze the bytes of the class in detail and check  
> for the presence of pause() and String call(Object) method calls on  
> an ElementSupport instance (MetricsMethodVisitor). When this  
> analysis detects that continuations are used, the actual byte-code  
> modification is performed.
>
> I suppose that the 'Element' notion should be abstracted and that  
> the package name should be configurable somewhere in the extracted  
> API (probably when the continuation engine is registered or  
> integrated).
>
> I hope this provides enough information to get you started, just  
> let me know here if something isn't clear.
>
> Best regards,
>
> Geert
>
> On 15-sep-05, at 13:13, Patrick Lightbody wrote:
>
>
>> In a previous email exchange with Geert, I mentioned that I wanted  
>> to help extract RIFE's continuation support and introduce it to  
>> WebWork. I think that RIFE in general is a very excellent  
>> application framework (not just a web development framework) and  
>> am especially pleased with the continuation support.
>>
>> As such, I was hoping Geert could give me a starting point on how  
>> to extract the continuation stuff. Once I get it working, I'll  
>> definitely be donating the extracted package back to RIFE or would  
>> be happy to include it in an existing project (such as OSCore, for  
>> example) if that is easiest.
>>
>> Patrick
>>
>> _______________________________________________
>> Rife-devel mailing list
>> Rife-devel@...
>> http://www.uwyn.com/mailman/listinfo/rife-devel
>>
>>
>>
>
> --
> Geert Bevin                       Uwyn bvba
> "Use what you need"               Avenue de Scailmont 34
> http://www.uwyn.com               7170 Manage, Belgium
> gbevin[remove] at uwyn dot com    Tel [phone]
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://www.uwyn.com/mailman/listinfo/rife-devel
>

[Geert Bevin]

http://rifers.org:8088/viewrep/rifers/rife/trunk

or

https://svn.rifers.org/rife/trunk/

:-)
On 16-sep-05, at 07:49, Patrick Lightbody wrote:

> One question: where is the source repo? :)

--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel [phone]

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net