tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Jsp scripting elements revisited
Date Mon, 24 Jan 2000 16:06:30 GMT wrote:

> It seems to me that we are converging.  But just to make sure, lets start
> over with a clean slate, and I will try again, this time expressing my
> desires in the form of questions.
> Danno wrote:
> > <> wrote:
> > >
> > > I'll probably do that as an initial step, but my real interest is in
> > > usurping the meanings of things like <% %> while still providing a
> >
> > Usurping the meaning of a core element like that means you are changing
> the
> > spec.  The very need to describe an action as usurping is revolutionary
> to
> > the core.
> Perhaps a poor choice of words on my part.  It seems to me that the intent
> of the spec is precisely for
>    < language="perl"/>
> to change the way in which subsequent
>    <% $out->println("hello world!"); %>
> should be interpreted.
> As near as I can tell, while the spec alludes to support for languages
> other than Java, it provides no guidance as to how such languages are to be
> defined to the implementation.
> So my initial questions are:
> 1) Is my interpretation of the page directive above correct?

I believe so, and the same would apply to:

    <%@ page language="perl" %>

in the non-XML version of the syntax.

> 2) Anybody have any suggestions on the shape and form of the interfaces
> that Jasper should provide in order to enable third parties to "plug in"
> language support?

I haven't thought a lot about this before, but it seems that you've got at
least three high level strategies to consider:

- Continue to have Jasper generate servlet source code
  written in Java, translating <% %> scriptlets written in
  other languages to their Java equivalents.  (Probably not
  possible in the general case).

- Continue to have Jasper generate servlet source code
  in Java, but encapsulate scriptlet content into functions
  in their native language (Perl in your example), and then
  embed a Perl interpreter in your Java deployment.  (Dealing
  with side effects like variable declarations would be
  pretty interesting).

- Have Jasper generate a complete servlet equivalent in the
  other language, and execute it on top of a library that provides
  hooks back in to the server engine.

Which high level approach you take would seem to dramatically affect how to
modularize interfaces into Jasper.  What approach have you been taking in your
explorations so far?  (It would be quite useful to see that code, even if it
isn't proposed as a "revolution" per se).

> If we come to consensus on these two, it is my intent to make it so.
> - Sam Ruby
> P.S.  Both questions above were formed in such a was as to not require any
> changes to the current spec.  Follow on questions, particularly to the
> first one, will not be so clear.   Example: if an alternate language is
> chosen, will there ever be a need to "escape back into Java", and if so
> should this be up to the various implementations or speced in a portable
> manner?  My tactical error in this discussion was starting this discussion
> in the middle and presuming an answer.

On issues like this, the real question is "what, if anything, does the JSP 1.1
spec mean in this regard?"  There may be no defined answer for 1.1, but the
issues raised might be dealt with in future spec versions.  It would probably
be most appropriate to address such interpretation questions to Eduardo
Pelegri-Llopart, the JavaSoft guy who is managing the JSP spec's evolution.  I
think he monitors TOMCAT-DEV (although probably not as often as

Craig McClanahan

View raw message