tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: Multiple languages for Jasper
Date Tue, 19 Oct 1999 04:06:55 GMT


dIon Gillard wrote:

><conversation-starter>
>
>I'd like to start work on implementing multiple language support for
>Jasper.

So would I!  Let's work together!

>My main interest is in NetRexx support, but i'll assume lots of other
>people will want other stuff, and we should take this into consideration.

Mike Cowlishaw will be pleased when he hears that NetRexx was the first language
mentioned on Jakarta!

You will be pleased to know that we already have NetRexx as well as NetScape's
Rhino implementation of Javascript integrated with Jakarta.  We have a fair
number of other languages working but not ready to be shipped - some compiled to
byte codes, others are Java based interpreters, and still others are C-based
interpreters.

>One of the IBM people working on BSF popped up on the general list and
>offered to integrate it into Jakarta, but I'll need that explained before I
>understand how it will work.

I'm another one of those pesky IBMers, who has among other things, contributed
to BSF.  Let me give an example of what is working today:

   <html>
   <jsp:directive.page language="netrexx"/>
   <head><title>Hello from NetRexx</title></head>
   <body>
   <h1>
   <jsp:scriptlet>
     out.println("Hello World! (from NetRexx)");
   </jsp:scriptlet>
   </h1>
   </body>
   </html>

OK, so this example doesn't look much different than a standard JSP page, and
other than the funny directive on the second line, you wouldn't know the
difference.  At least, not until you try adding more code in between the
scriptlet tags...

>My proposal:
>     Parse the .jsp into an intermediate, language independent XML
>document.
>     Use configuration parameters to decide which class is used to compile
>a page for a given language
>     Each class needs to parse the XML intermediate doc, (generate source &
>compile if needed) to produce a class file.

Our approach to date has been somewhat less radical than this.  Before
considering a major rewrite of the parser, I would suggest that it is probably
worth understanding what is possible within the scope of the current parser.

Overview of the changes we have made:

* parseeventlistener.java is modified to allow attributes to be passed on handle
declaration, expression, and scriptlet methods.  In particular, a language
attribute is looked for.

* compiler.java is modified to scan for attributes on the declaration,
expression, and scriptlet tags.

* jspparseeventlistner.java has these same three methods modified to say in
essence "if language equals java, do what is done today, else call
bsfBlockHandler."  Minor other changes are made to declare objects that BSF
uses, etc.

* bsfblockhandler.java is introduced to do the interfacing to BSF.




Mime
View raw message