Fulcrum and Avalon Service Musings ....

[Siegfried Goeschl <si...@it20one.at>]

Hi folks,

a short update about the ongoing work of the Turbine/Fulcrum community 
inspired a little bit by recenct posting about adding JUnit tests to 
JAMES ....

Fulcrum Script Service
=================================================
I wrote a  JSR 223 ("Scripting for the Java Platform") integration as 
Avalon Component  called "Fulcrum Script Service" which can be found at 
http://jakarta.apache.org/turbine/fulcrum/fulcrum-script/index.html
 - JSR 223 provides an API for scripting of Java applications. The 
service is currently based on the libraries of the SUN reference 
implementation and I got Rhino and Groovy running. In the meantime there 
were changes of the API (as part of the Mustang development) and I hope 
to succeed with a backport to JDK 1.4 with additional support of 
BeanShell and Pnuts. Special thanks to Patrich Niemeyer (author of 
BeanShell), Toyokazu Tomatsu  (author of Pnuts) and Mike Grogan (JSR 223 
specification lead) - just in case they read this email ... :-)

JSR 223 provides news of thinking application design since it enables 
application flow scripting independent of the script language. I 
currently use it for scripting the control flow in one of my 
applications. All of the infrastructure is provided as Avalon service 
where the customization is done as Rhino scripts consisting of parsing 
of a property file, loading a few PDF documents based on the content of 
the property file, signing them, generate and sending a MimeMessage. JSR 
223 is also applicable for scripting of webapplications - maybe we see a 
JSR 223 integration of Velocity?!

The current implementation is tied to YAAFI container (due to the Avalon 
Context entries using the Merlin conventions) but I give it a go to make 
it compatible with Fortress and Phoenix.

AOP Support for Avalon Services
=================================================
During the last few months when I spent a hew hours a week riding the 
train I had a look at Spring (thanks to Juergen Hoeller for his talk at 
the JUGAT) and Hivemind - as part of the train riding I added 
interceptor support to YAAFI - see 
http://jakarta.apache.org/turbine/fulcrum/fulcrum-yaafi/interceptors/index.html. 
Since interceptors per se are a little boring I also wrote a few 
interceptor service - logging, performance and a JAMON integration. What 
I would like to do during the next few weeks is to decouple the whole 
interceptor package from the YAAFI container and make it a stand-alone 
Avalon service, i.e. it could be used by any Avalon container out there 
(Reinhard - even ECM+). Well, integrating it into an existing Avalon 
container is a different topic but this is a problem I face anyway. The 
goal is to provide basic AOP support (similiar to Spring) with minimal 
dependencies

AOS - Aspect-Oriented Scripting
=================================================
This is actually the target of the current efforts - I would like to 
combine JSR 223 with AOP to modify the behavious of services after 
deployment.

The usage scenario - your customers, e.g. during the first installation 
of your product you learn that you have to set an email header because 
an input file contains a particular name/value pair. Nobody told you 
that (well, you actually were puzzled about all those name/value pairs 
to begin with) and you know that no easy way to tell your mail sending 
component to set this particular email header which contains metadata 
for the document archiving system. Of course you could hack  the 
solution but tomorrow there is (hopefully) the next customer with a 
different but equally odd feature request. And adding a dozen of those 
odd feature results in a software where you would like to delete the 
author tag in javadocs. But it would be so easy to intercept the service 
parsing the property file, compute the email header and store it in a 
Thread Local Storage and use a second interceptor to sneak this email 
header into your MimeMessage. And if you would have a scripting language 
at hand you could do it NOW and HERE.


Cheers,

Siegfried Goeschl


PS: If anyone is interested in lending a hand just tell me ... :-)

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