You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bsf-dev@jakarta.apache.org by Sanjiva Weerawarana <sa...@watson.ibm.com> on 2003/05/07 09:13:09 UTC
re-organizing the BSF source tree
It seems to me that the BSF src tree can stand some re-org.
For example, to get to the src currently you have to go to:
jakarta-bsf/src/bsf-2.3/bsf/src/org/apache/bsf
Note that that path has "bsf" and "src" repeated .. not good.
Also, I haven't yet found the samples ..
I'd like to re-org the src tree. Are there any willing helpers?
I think we need the usual structure:
jakarta-bsf/
src/
samples/
lib/
[whatever other stuff at the top level]
jakarta-bsf/src/
org/
apache/
bsf/
...
What's in the taglib, bsf_debug, jsdb directories? How should those
fit in?
Sanjiva.
Re: re-organizing the BSF source tree
Posted by "Victor J. Orlikowski" <vj...@dulug.duke.edu>.
So, back to the topic at hand...
Let's temporarily semi-ignore the issue of JSPs and BSF; I'd like
to get to the work of fixing up the source tree ASAP.
Is the debug stuff egregious enough to rip out immediately?
Probably; anyone else back me up?
If so, the taglib bit needs to be fixed, should we decide to keep
it for BSF + JSP. How should we leave this code w/i the BSF source
tree (realizing it's not really meant to be there, anyway)? Rip it
out (but store it someplace), or some odd kind of source tree
setup?
Looking for opinions,
Victor
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
==================================================================
orlikowski@apache.org | vjo@dulug.duke.edu | vjo@us.ibm.com
Re: re-organizing the BSF source tree
Posted by "Victor J. Orlikowski" <vj...@dulug.duke.edu>.
On Sun, Jun 15, 2003 at 11:30:36PM +0600, Sanjiva Weerawarana wrote:
> Can you give me more info on "EL"? I am not familiar with it ..
>
As Bill mentioned, it's part of the Commons project.
It is also part of the proposed JSP 2.0 spec (Chapter JSP.2),
having been introduced via JSTL 1.0. It is extended in the JSP 2.0
spec, and the maintenance JSTL 1.1 will be released to match that
extension.
Victor
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
==================================================================
orlikowski@apache.org | vjo@dulug.duke.edu | vjo@us.ibm.com
Re: re-organizing the BSF source tree
Posted by Bill Stoddard <bi...@wstoddard.com>.
Sanjiva Weerawarana wrote:
>>2) The taglib directory also needs to go. With JSP 2.0 upcoming, I
>>believe that BSF has a limited role, if any, in JSPs - EL does a
>>*much* better job in its place. The taglib in this source tree was
>>
>>
>
>Can you give me more info on "EL"? I am not familiar with it ..
>
EL is the expression language from JSTL, now part of the JSP 2.0 spec.
http://jakarta.apache.org/commons/el.html
Bill
BSF, DHTML ,... (Re: re-organizing the BSF source tree
Posted by "Rony G. Flatscher" <Ro...@wu-wien.ac.at>.
>
>
>> a) ad "usage of scripting languages in the context of JSP is rather
>> unnatural": why *unnatural*, for God's sake? I see the contrary to be
>> true, opening up JSPs to solving problems in non-Java languages as
>> well, *if* fitting. As important as Java is, there are
>> applications/problems where non-Java-languages may be preferable,
>> e.g. from scripting to interpreting dynamically created statements.
>> [BTW, Microsoft allows to use *any* scripting language for their ASP,
>> ie. the JSP counterpart on Windows: they support any WSH-scripting
>> language out of the box.]
>
> Could not resist to put few words. I think it is better to let each
> scripting language to connect to JSP directly without intermediate
> layer of BSF. The issue here is not a performance (I doubt that BSF
> layer has
Well, the "intermediate layer BSF" is exactly the plumming one needs to
have available to *easily* allow Java programs to invoke non-Java
languages and allow those to "call back" into Java.
Or with other words: if there was no BSF available one would have to
re-invent and re-implement most of the functionality which BSF offers
for "free". So your suggestions would impose more workload on the
shoulders of people trying to bridge Java with other programming
languages, resulting in numerous different implementations of that
particular bridging (and in addition each individually created plumming
infrastructure would have to be tested individually).
OO-programming is about re-using, frameworks the same. Having BSF in
place already allows one to re-use a tested framework and thereby
cutting development costs and debugging time (w.r.t. the BSF
infrastructure).
> any significant impact here) but simplicity and convenience of direct
> plugin implementation over using BSF as super-plugin that comes with
> own plugin children.
Oh, BSF is about elegant simplicity, there is no overhead imposed by BSF
which you wouldn't have to create yourself (just think about the issue
of creating event adapters yourself, not speaking of the need of
reflection, just look into the BSF source code to see what those people
have nicely achieved!).
Or putting it into even other words: if someone sees the need to bridge
Java with another programming language (which should also be able to
"call back"), I would regard it to be a stupid decision, not to take
advantage of BSF, which solves the principal briding problems.
> After spending few years to implement all MSIE quirks and extensions
> for JavaScript and DOM in a pure Java browser while keeping an option
> to use
> Jython on web pages I think any intermediate library will either harm
> a particular language power or lead to extremely complex and
> unmaintainable library.
That depends on the chosen implementation.
> Microsoft tried to allow to use VBScript in HTML and keep things
> compatible with Netscape DOM bindings for JavaScript and the end
> result is the complete and final mess in DOM scripting in MSIE that I
> suspect nobody understand.
I do not concur with this view, DOM in the context of a WWW-browser by
itself is a rather complex biest and there are too many people not even
knowing about DOM but using DHTML by extending existing examples.
Also, the WWW-browser area is one area which upsets me if you witness
the phenomenon, that for all practical purposes JavaScript only is
supported out of the box for scripting HTML pages. MS Internet Explorer
being the *only* browser which supplies an "open" (it is *not* that open
at all) interface for people to allow other scripting languages to be
used for that purpose, out of the box: JScript and VBScript (it may have
been for the VisualBasic language that MS opened its browser for more
than JavaScript to be used for scripting HTML pages).
> Server side ASP is not better. Yes, you can write ASP in JavaScript or
> Perl, but often you end up with terrible hacks just to subvert ASP
> VBScript-based conventions into a particular language.
No! I know, I have been doing that exact thing for quite some years as
well. No need to use VBScript semantics at all (but one could use the
VBScript sample programs as well as the JScript sample programs to learn
what can be done with WSH).
> Similarly Python and JavaScript are just too different to have a
> simple library that covers everything.
Well, you need to implement the ActiveX interfaces for the Windows
Script Host (WSH) engines (WSE), which is not an easy task, because
AFAIK not all vital information is documented (I remember at one time
that ASP was not possible with a particular programming language due to
a necessary registry entry one had to supply; if you didn't supply that
by default a VBScript prolog and epilog was "injected"). [Any
WSE-compliant programming language can be applied for MSIE, ASP and
{c|w}script applications and any other scriptable WSH application. It
is even possible to define COM classes, implemented in such scripting
languages.]
An brief overview about scripting/automation under Windows (starting out
with COM, ending with .NET) with a programming language with a syntax
like pseude-code (so the code should be ledgible/understandable by
non-proficient persons as well) can be found at:
<http://wi.wu-wien.ac.at/rgf/diplomarbeiten/2003_Helmecke_A/MasterThesis_AutomationOfWindowsApplicationsWithObjectRexx.pdf>
It uses Object Rexx, a commercial product by IBM (I am not affiliated
with IBM at all, sometimes just a happy customer) freely available for
Linux and OS/2, costs a little fee for AIX and Windows (but freely
available for educational institutions for the purpose of teaching and
researching via IBM's "Scholar" program).
Regards,
---rony
P.S.: There is a JCP initiative at Sun to explicitly allow Java to
invoke scripting languages, cf. <http://www.jcp.org/en/jsr/detail?id=223>.
Re: re-organizing the BSF source tree
Posted by Igor Bukanov <ig...@fastmail.fm>.
Rony G. Flatscher wrote:
>> Oh, one more thing pops to mind... use of scripting languages from the
>> Java environment of JSP is rather unnatural. Passing script variables
>> back and forth between java and the scripting language environment is
>> messy and needs some hacks to jasper. Chuck or Victor should be able
>> to provide more detail.
>
>
>
> a) ad "usage of scripting languages in the context of JSP is rather
> unnatural": why *unnatural*, for God's sake? I see the contrary to be
> true, opening up JSPs to solving problems in non-Java languages as well,
> *if* fitting. As important as Java is, there are applications/problems
> where non-Java-languages may be preferable, e.g. from scripting to
> interpreting dynamically created statements.
> [BTW, Microsoft allows to use *any* scripting language for their ASP,
> ie. the JSP counterpart on Windows: they support any WSH-scripting
> language out of the box.]
Could not resist to put few words. I think it is better to let each
scripting language to connect to JSP directly without intermediate layer
of BSF. The issue here is not a performance (I doubt that BSF layer has
any significant impact here) but simplicity and convenience of direct
plugin implementation over using BSF as super-plugin that comes with own
plugin children.
After spending few years to implement all MSIE quirks and extensions for
JavaScript and DOM in a pure Java browser while keeping an option to use
Jython on web pages I think any intermediate library will either harm a
particular language power or lead to extremely complex and
unmaintainable library.
Microsoft tried to allow to use VBScript in HTML and keep things
compatible with Netscape DOM bindings for JavaScript and the end result
is the complete and final mess in DOM scripting in MSIE that I suspect
nobody understand. Server side ASP is not better. Yes, you can write ASP
in JavaScript or Perl, but often you end up with terrible hacks just to
subvert ASP VBScript-based conventions into a particular language.
Similarly Python and JavaScript are just too different to have a simple
library that covers everything.
Regards, Igor
Re: re-organizing the BSF source tree
Posted by "Rony G. Flatscher" <Ro...@wu-wien.ac.at>.
>
>
>> Jasper does not use it and I really don't think using BSF in this
>> role (as a way to script enable JSPs) is the 'right thing to do'.
>> First major problem is abysmal performance. Second major problem is
>> with debugging. The second problem can probably be solved(?). I
>> don't see how the first problem can be solved.
>>
>> Bill
>
> Oh, one more thing pops to mind... use of scripting languages from the
> Java environment of JSP is rather unnatural. Passing script variables
> back and forth between java and the scripting language environment is
> messy and needs some hacks to jasper. Chuck or Victor should be able
> to provide more detail.
a) ad "usage of scripting languages in the context of JSP is rather
unnatural": why *unnatural*, for God's sake? I see the contrary to be
true, opening up JSPs to solving problems in non-Java languages as well,
*if* fitting. As important as Java is, there are applications/problems
where non-Java-languages may be preferable, e.g. from scripting to
interpreting dynamically created statements.
[BTW, Microsoft allows to use *any* scripting language for their ASP,
ie. the JSP counterpart on Windows: they support any WSH-scripting
language out of the box.]
b) ad "abysmal performance": could you elaborate, please? Have not seen
*any* *abysmal* performance yet. What applications are you talking about
and what languages, and what do you judge to be "abysmal performance"??
What are you using/employing BSF for?
Regards,
---rony
Re: Using BSF to implement JSP language attribute (was: re-organizing the BSF source tree)
Posted by "Victor J. Orlikowski" <vj...@dulug.duke.edu>.
On Wed, Jun 18, 2003 at 10:06:42AM +0600, Sanjiva Weerawarana wrote:
> > The crux of the issue, I have found, is that either you have to
> > manage bytecode so that the correlation to the original source is
> > maintained, or you deal with the fact that you have an interpreter
> > running under java, and realize the performance loss and loss of
> > coherent debugging.
>
> So really what you're saying applies whether Rhino, for example,
> is integrated to Jasper directly or via BSF. If that's true then
> how do you actually use another language in JSPs? Maybe compile
> the entire page into a servlet in that language? (That'll work as
> long as you have the entire page using one language I guess.)
>
Yes, it applies in both cases.
And the answer is, you use the language in a decidedly suboptimal
manner. I think that JSR-223 (just getting started) has been
created to address that issue to some extent, but how far it will
get is anyone's guess.
I think the best case integration/performance scenario comes from
management of bytecode. I also think that the management code
would be hairy as all get out, if nothing else.
> > Standard trade-off of performance vs. maintainability, as far as I
> > can tell.
>
> Maintainability? You mean in terms of debugging I assume.
>
In terms of keeping track of how the generated bytecode from any
particular language engine capable of compilation equates to line
numbers in the original source when doing postprocessing. So yes,
from the perspective of debugging.
> > Works, yes. Mostly. There are cross-environmental issues that crop
> > up. Performance-wise, once the generated servlet is created, the
> > main BSF hit is re-interpreting the script that is passed to the
> > engine every time the page is loaded - not bad for only a few
> > concurrent clients; awful starting around 500 or more.
>
> Recompiling the script problem can be fixed easily for scripting
> languages that support compilation. For those that don't such is
> life.
>
Yes. We can cache the bytecode. Not a problem, I agree - but the
debugging maintainability tradeoff appears.
> I agree seemless integration would be very nice and my comment about
> Matt's initial integration was rather stupid .. sorry.
>
Don't worry about it.
> However, there are lots of people who are happily developing lots
> of real applications using LAMP (linux, apache, mysql and php). I'd
> be surprised to hear that they have fully integrated seamless
> debugging etc. in that environment. However, it works and they are
> happily building apps.
>
Agreed. Perhaps the best suggestion is to try to ensure that any
possible interaction between the language environments is handled
as well as possible, and debugging is limited to a simple error
reporting mechanism (that the JSP compilation handles via an error
page if there is a blow-up). I can believe in that, though I think
the management of the interaction between compiled scripts and the
generation of the servlet will be more complex than anyone
expects (imagine Jasper compiling a page, hits a script, compiles
it; hits a taglib call later in the page, that wants to read/write a
variable that's in the compiled script - do you now load the
script to get the value? What if the script modifies some backend
data store every time it's called?).
> Do we want to enable a php user to write JSPs and move them to
> the Java platform? How would you integrate php to Jasper with or
> without BSF?
>
I'm not sure I would. :)
All you would be buying for the php migrator to JSP would be
syntax - unless you're suggesting that you make available the
entire library of php functions to which the migrator would be
used. And then, what incentive do they have to learn JSP, unless
we cripple the php that's available to force them to use the
implicit objects.
In that case, all that gets offered is the "security blanket" of
familiar syntax, when they get dumped into learning a new object
model.
And there's really no point in writing a php parser that generates
servlets, IMO.
So, as I stated in the beginning, I think EL is the way to go.
Syntax is based off of a combination of XPath and EcmaScript, it
is required in the JSP 2.0 spec, the document becomes similar in
appearance to php, and all of the Java objects are available
- a big win, at the cost of new syntax comparable in complexity to
php.
I'm really unsure why the language attribute was added to the page
directive in the first place, w/o something like JSR-223 and
JSR-045 having been defined first.
Just my thoughts,
Victor
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
==================================================================
orlikowski@apache.org | vjo@dulug.duke.edu | vjo@us.ibm.com
Re: Using BSF to implement JSP language attribute (was: re-organizing the BSF source tree)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
"Victor J. Orlikowski" <vj...@dulug.duke.edu> writes:
>
> One example of where you get into problems is when you have folks
> who want to combine taglibs and BSF, and are confused as to why
> script variables aren't necessarily immediately available within
> taglibs. Sure, someone who understands that BSF is under the
> covers realizes that the scripting language execution environment
> is running within the generated servlet; one could probably
> alleviate the problem by ensuring that accesses to variables by
> taglibs are arranged to check in BSF if not found in the generated
> servlet.
Sounds good.
> But then, you have bigger problems too. Debugging such a mixed
> execution environment becomes a flying circus. Are you in the
:) Agreed.
> generated servlet, or in the scripting language hanging off of
> BSF? Assuming you have a debugger that supports stepping in both
> bytecode and the script interpreter, if you start stepping in the
> BSF code (which normally gets handed off as a string to BSF by the
> page compiler, and therefore needs some kind of line information
> to point back to the original JSP), do you continue stepping upon
> re-entry into the generated servlet when you fall off the end of
> the script (You should, but it becomes difficult - granted,
> JSR-045 adds debug info to non-Java languages by post-processing
> class files to munge the LineNumberTable and SourceFile
> attributes; but that means having BSF compile the script to
> bytecode - which will improve performance, so long as it is cached
> - and then having Jasper post-process the BSF-generated bytecode by
> merging it w/ the bytecode from the compilation of the generated
> servlet and then munging the LineNumberTable and SourceFile
> attributes. This is not fun or easy; I have not had great success
> at attempts I have made recently to do so - but I will heap great
> praise upon the one who does :).
I certainly understand that solving this properly is not easy
by any means and may not even be possible.
> The crux of the issue, I have found, is that either you have to
> manage bytecode so that the correlation to the original source is
> maintained, or you deal with the fact that you have an interpreter
> running under java, and realize the performance loss and loss of
> coherent debugging.
So really what you're saying applies whether Rhino, for example,
is integrated to Jasper directly or via BSF. If that's true then
how do you actually use another language in JSPs? Maybe compile
the entire page into a servlet in that language? (That'll work as
long as you have the entire page using one language I guess.)
> Standard trade-off of performance vs. maintainability, as far as I
> can tell.
Maintainability? You mean in terms of debugging I assume.
> > Matt Duftler first integrated BSF to the WebSphere JSP compiler in
> > March '99 in about 4 hours .. we even had XSLT integrated. It
> > worked pretty fine. Of course performance was not anywhere close
> > to Java and there was no debug story, but it definitely worked
> > fine.
>
> Works, yes. Mostly. There are cross-environmental issues that crop
> up. Performance-wise, once the generated servlet is created, the
> main BSF hit is re-interpreting the script that is passed to the
> engine every time the page is loaded - not bad for only a few
> concurrent clients; awful starting around 500 or more.
Recompiling the script problem can be fixed easily for scripting
languages that support compilation. For those that don't such is
life.
> Sanjiva, it's not a question of integration; it's a question of
> *seamless* integration, that will not confuse new users. That's
> what's lacking, and missing a good way to solve.
I agree seemless integration would be very nice and my comment about
Matt's initial integration was rather stupid .. sorry.
However, there are lots of people who are happily developing lots
of real applications using LAMP (linux, apache, mysql and php). I'd
be surprised to hear that they have fully integrated seamless
debugging etc. in that environment. However, it works and they are
happily building apps.
Do we want to enable a php user to write JSPs and move them to
the Java platform? How would you integrate php to Jasper with or
without BSF?
Sanjiva.
Re: Using BSF to implement JSP language attribute (was: re-organizing the BSF source tree)
Posted by "Victor J. Orlikowski" <vj...@dulug.duke.edu>.
On Mon, Jun 16, 2003 at 10:48:26PM +0600, Sanjiva Weerawarana wrote:
> "Bill Stoddard" <bi...@wstoddard.com> writes:
> > I welcome some good hearty discussion on this topic. Chuck and Victor
> > have convinced me that BSF is just not the right solution for script
> > enabling JSP's but they might be making some faulty assumptions.
Possible, without a doubt. :)
>
> I would like to learn why its not the right way too .. I don't
> see how one could impl it generally without something like BSF.
>
BSF provides the means for loading the desired language, and
registering the implicit JSP objects, sure. And I agree that
there's probably not better way to implement it. But.
One example of where you get into problems is when you have folks
who want to combine taglibs and BSF, and are confused as to why
script variables aren't necessarily immediately available within
taglibs. Sure, someone who understands that BSF is under the
covers realizes that the scripting language execution environment
is running within the generated servlet; one could probably
alleviate the problem by ensuring that accesses to variables by
taglibs are arranged to check in BSF if not found in the generated
servlet.
But then, you have bigger problems too. Debugging such a mixed
execution environment becomes a flying circus. Are you in the
generated servlet, or in the scripting language hanging off of
BSF? Assuming you have a debugger that supports stepping in both
bytecode and the script interpreter, if you start stepping in the
BSF code (which normally gets handed off as a string to BSF by the
page compiler, and therefore needs some kind of line information
to point back to the original JSP), do you continue stepping upon
re-entry into the generated servlet when you fall off the end of
the script (You should, but it becomes difficult - granted,
JSR-045 adds debug info to non-Java languages by post-processing
class files to munge the LineNumberTable and SourceFile
attributes; but that means having BSF compile the script to
bytecode - which will improve performance, so long as it is cached
- and then having Jasper post-process the BSF-generated bytecode by
merging it w/ the bytecode from the compilation of the generated
servlet and then munging the LineNumberTable and SourceFile
attributes. This is not fun or easy; I have not had great success
at attempts I have made recently to do so - but I will heap great
praise upon the one who does :).
The crux of the issue, I have found, is that either you have to
manage bytecode so that the correlation to the original source is
maintained, or you deal with the fact that you have an interpreter
running under java, and realize the performance loss and loss of
coherent debugging.
Standard trade-off of performance vs. maintainability, as far as I
can tell.
> Matt Duftler first integrated BSF to the WebSphere JSP compiler in
> March '99 in about 4 hours .. we even had XSLT integrated. It
> worked pretty fine. Of course performance was not anywhere close
> to Java and there was no debug story, but it definitely worked
> fine.
Works, yes. Mostly. There are cross-environmental issues that crop
up. Performance-wise, once the generated servlet is created, the
main BSF hit is re-interpreting the script that is passed to the
engine every time the page is loaded - not bad for only a few
concurrent clients; awful starting around 500 or more.
Sanjiva, it's not a question of integration; it's a question of
*seamless* integration, that will not confuse new users. That's
what's lacking, and missing a good way to solve.
Victor
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
==================================================================
orlikowski@apache.org | vjo@dulug.duke.edu | vjo@us.ibm.com
Re: Using BSF to implement JSP language attribute (was: re-organizing the BSF source tree)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
"Bill Stoddard" <bi...@wstoddard.com> writes:
> I welcome some good hearty discussion on this topic. Chuck and Victor
> have convinced me that BSF is just not the right solution for script
> enabling JSP's but they might be making some faulty assumptions.
I would like to learn why its not the right way too .. I don't
see how one could impl it generally without something like BSF.
Matt Duftler first integrated BSF to the WebSphere JSP compiler in
March '99 in about 4 hours .. we even had XSLT integrated. It
worked pretty fine. Of course performance was not anywhere close
to Java and there was no debug story, but it definitely worked
fine.
Chuck/Victor?
Sanjiva.
RE: Using BSF to implement JSP language attribute (was: re-organizing the BSF source tree)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Yep, I am a java poser, but I'm trying hard to learn new tricks :-)
I did *not* say that. LOL
> I welcome some good hearty discussion on this topic. Chuck and Victor
> have convinced me that BSF is just not the right solution for script
> enabling JSP's but they might be making some faulty assumptions.
I don't know if we're talking about "faulty" assumptions, so much as just
different ones. For example, all three of you are HTTPD developers who also
work on BSF, whereas Sanjiva works more with Java-based web services and
BSF.
Benchmarking, as I've done recently, Apache -> mod_jk2 (UNIX domain
sockets) -> Tomcat 4.1, shows the somewhat expected *huge* difference in
performance between httpd and tomcat.
Server Software: Apache/2.0.40 Apache/2.0.40
Server Hostname: tomcat httpd
Server Port: 80 80
Document Path: / /
Document Length: 3779 bytes 5979 bytes
Concurrency Level: 50 50
Time taken for tests: 41.067 seconds 8.653 seconds
Complete requests: 10000 10000
Failed requests: 0 0
Broken pipe errors: 0 0
Keep-Alive requests: 0 0
Total transferred: 40210000 bytes 62866692 bytes
HTML transferred: 37790000 bytes 59891643 bytes
Requests per second: 243.50 [#/sec] (mean) 1155.67 [#/sec] (mean)
Time per request: 205.34 [ms] (mean) 43.27 [ms] (mean)
Time per request: 4.11 [ms] 0.87 [ms] [across
concurrent requests]
Transfer rate: 979.13 7265.31 [Kbytes/sec]
received
Performance is certainly relative. Even using If-Modified-Since, for which
I have support in most of my dynamic content generation pages, the
performance improvement is only double, and the CPU load remains high:
Requests per second: 395.41 [#/sec] (mean)
Time per request: 126.45 [ms] (mean)
Time per request: 2.53 [ms] (mean, across all concurrent requests)
Transfer rate: 51.40 [Kbytes/sec] received
However ... relating back to the discussion at hand, this appears to suggest
that the vast majority of the overhead of serving a JSP page is not the page
execution, itself. The 304 handling short-circuits the JSP page in the
service() method; the page ISN'T executed, and the 304 code is immediately
returned.
I have not benchmarked tomcat directly at this time, so I can't tell you if
the overhead is inside of Tomcat, or in the connector. I'll cc Costin to
see if he cares to shed any light on that specific topic.
--- Noel
Re: Using BSF to implement JSP language attribute (was: re-organizing
the BSF source tree)
Posted by Bill Stoddard <bi...@wstoddard.com>.
Noel J. Bergman wrote:
>>IBM has had this working for some years in their WebSphere adaptation of
>>
>>
>Tomcat,
>
>
>>so I would venture to suggest that they represent at least one set of
>>
>>
>domain
>
>
>>experts.
>>
>>
>
>Yes, I realize that you are IBM's Apache HTTPD person. :-)
>
Yep, I am a java poser, but I'm trying hard to learn new tricks :-)
>
>There appears to be a difference of opinion between you and Sanjiva
>Weerawarana relative to using BSF to implement the language attribute. Is
>this based upon different needs? What feedback does IBM have from WebSphere
>customers related to using the language attribute in WebSphere?
>
> --- Noel
>
I welcome some good hearty discussion on this topic. Chuck and Victor
have convinced me that BSF is just not the right solution for script
enabling JSP's but they might be making some faulty assumptions.
Bill
RE: Using BSF to implement JSP language attribute (was: re-organizing the BSF source tree)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> IBM has had this working for some years in their WebSphere adaptation of
Tomcat,
> so I would venture to suggest that they represent at least one set of
domain
> experts.
Yes, I realize that you are IBM's Apache HTTPD person. :-)
There appears to be a difference of opinion between you and Sanjiva
Weerawarana relative to using BSF to implement the language attribute. Is
this based upon different needs? What feedback does IBM have from WebSphere
customers related to using the language attribute in WebSphere?
--- Noel
Using BSF to implement JSP language attribute (was: re-organizing the BSF source tree)
Posted by "Noel J. Bergman" <no...@devtech.com>.
>Sanjiva Weerawarana wrote:
>>
>>"Noel J. Bergman" <no...@devtech.com> writes:
>>>BSF could, and probably should, be used to implement the language
>>>attribute.
>>
>>We did that internally for our JSP compiler back in '99. I thought
>>that got contributed to Jasper, but I could be wrong.
>>If it hasn't then definitely that's a worthwhile thing to do IMHO
>>as it allows any BSF language to be used to write a JSP.
>>Does anyone know for sure whether Jasper uses it or not?
>
> Jasper does not use it and I really don't think using BSF in this role
> (as a way to script enable JSPs) is the 'right thing to do'.
You have a better alternative proposal to implement the language attribute?
> First major problem is abysmal performance.
> I don't see how [this] problem can be solved.
Interpreted languages don't have to have the performance of the native JVM.
The more that BSF is used, the more impetus to push performance. What do
you see as the BSF contributed overhead, compared to the performance of the
underlying language engine, and the obstacles to reducing overhead?
> Second major problem is with debugging.
> The second problem can probably be solved(?).
Well, then its not much of a problem, is it? :-)
> Oh, one more thing pops to mind... use of scripting languages from the
> Java environment of JSP is rather unnatural.
Unnatural or not in the internals, it is part of the JSP Specification. IBM
has had this working for some years in their WebSphere adaptation of Tomcat,
so I would venture to suggest that they represent at least one set of domain
experts. What are hacks in their jasper patch could be re-engineered more
cleanly, right?
--- Noel
Re: re-organizing the BSF source tree
Posted by Bill Stoddard <bi...@wstoddard.com>.
Bill Stoddard wrote:
> Sanjiva Weerawarana wrote:
>
>> "Noel J. Bergman" <no...@devtech.com> writes:
>>
>>
>>> BSF could, and probably should, be used to implement the language
>>>
>>
>> attribute.
>>
>> We did that internally for our JSP compiler back in '99. I thought
>> that got contributed to Jasper, but I could be wrong.
>>
>> If it hasn't then definitely that's a worthwhile thing to do IMHO
>> as it allows any BSF language to be used to write a JSP.
>>
>> Does anyone know for sure whether Jasper uses it or not?
>>
> Jasper does not use it and I really don't think using BSF in this role
> (as a way to script enable JSPs) is the 'right thing to do'. First
> major problem is abysmal performance. Second major problem is with
> debugging. The second problem can probably be solved(?). I don't see
> how the first problem can be solved.
>
> Bill
Oh, one more thing pops to mind... use of scripting languages from the
Java environment of JSP is rather unnatural. Passing script variables
back and forth between java and the scripting language environment is
messy and needs some hacks to jasper. Chuck or Victor should be able to
provide more detail.
Bill
Re: re-organizing the BSF source tree
Posted by Bill Stoddard <bi...@wstoddard.com>.
Sanjiva Weerawarana wrote:
>"Noel J. Bergman" <no...@devtech.com> writes:
>
>
>>BSF could, and probably should, be used to implement the language
>>
>>
>attribute.
>
>We did that internally for our JSP compiler back in '99. I thought
>that got contributed to Jasper, but I could be wrong.
>
>If it hasn't then definitely that's a worthwhile thing to do IMHO
>as it allows any BSF language to be used to write a JSP.
>
>Does anyone know for sure whether Jasper uses it or not?
>
Jasper does not use it and I really don't think using BSF in this role
(as a way to script enable JSPs) is the 'right thing to do'. First major
problem is abysmal performance. Second major problem is with debugging.
The second problem can probably be solved(?). I don't see how the first
problem can be solved.
Bill
RE: re-organizing the BSF source tree
Posted by "Noel J. Bergman" <no...@devtech.com>.
The BSF web-site currently states that:
"In order to use BSF as part of the Tomcat servlet engine, you must
currently download patches from the BSF web site that permit Jasper to call
BSF. Instructions for this will be posted on the website, and will soon be
accompanied by prebuilt binaries. We hope that these changes will be merged
into Tomcat in the near future."
A brief check does not show anything about BSF being supported by Jasper,
yet, in either Tomcat v4.1 or v5.
I also suggest that the <scriptlet> and <expression> tags remain useful.
They let you write a particular piece of code in a language well suited for
that particular task. For example, what if I wanted XSLT for the page
language, and something else for a particular scriptlet or expression?
--- Noel
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Sunday, June 15, 2003 21:28
To: Bean Scripting Framework developers
Subject: Re: re-organizing the BSF source tree
"Noel J. Bergman" <no...@devtech.com> writes:
>
> BSF could, and probably should, be used to implement the language
> attribute.
We did that internally for our JSP compiler back in '99. I thought
that got contributed to Jasper, but I could be wrong.
If it hasn't then definitely that's a worthwhile thing to do IMHO
as it allows any BSF language to be used to write a JSP.
Does anyone know for sure whether Jasper uses it or not?
Sanjiva.
Re: re-organizing the BSF source tree
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
"Noel J. Bergman" <no...@devtech.com> writes:
>
> BSF could, and probably should, be used to implement the language
attribute.
We did that internally for our JSP compiler back in '99. I thought
that got contributed to Jasper, but I could be wrong.
If it hasn't then definitely that's a worthwhile thing to do IMHO
as it allows any BSF language to be used to write a JSP.
Does anyone know for sure whether Jasper uses it or not?
Sanjiva.
RE: re-organizing the BSF source tree
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 2) The taglib directory also needs to go. With JSP 2.0 upcoming, I
> believe that BSF has a limited role, if any, in JSPs - EL does a
> *much* better job in its place. The taglib in this source tree was
On the other hand, there is still the language attribute of the page
directive.
> I would argue that the currently existing BSF taglibs need killing
> too, based on the my belief that BSF and JSPs really shouldn't mix
BSF could, and probably should, be used to implement the language attribute.
--- Noel
Re: re-organizing the BSF source tree
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
"Victor J. Orlikowski" <vj...@dulug.duke.edu> writes:
>
> My apologies for the late entry into the discussion; it is only
> recently that I have been able to resolve some issues related to
> this very topic.
No problem - better late than never!
> Indeed, the source tree needs a complete re-org; I am certainly
> willing to help, or do it myself if no one else beats me to it
> (and no one objects to my stance on the issue).
>
> These are my thoughts on the issue:
> 1) bsf_debug and jsdb need to go. The debug interface, as it
> currently exists, is shameful, in performance and usefulness.
>
> 2) The taglib directory also needs to go. With JSP 2.0 upcoming, I
> believe that BSF has a limited role, if any, in JSPs - EL does a
> *much* better job in its place. The taglib in this source tree was
Can you give me more info on "EL"? I am not familiar with it ..
> a modification to support the aforementioned debug interface.
> Hence, it needs to go. I would argue that the currently existing
> BSF taglibs (in the taglibs project) need killing too, based on
> the my belief that BSF and JSPs really shouldn't mix (performance
> is abysmal, confusion stemming from having two separate contexts
> in the form of the generated servlet and the language engine
> executing script code within it, etc.)
>
> 3) Debug hooks need to be ripped out of the original BSF source,
> and we thereby return to the code as it was in 2.2, modulo some
> bugfixes.
Big +1 to this!
> As to what should be in the source before another release passes
> us, is a means, as suggested around January, for languages to be
> auto-detected at runtime, so that we do not have to incorporate
> every language engine under the sun into BSF. This makes life
> easier from a maintenance standpoint, as well as permitting
> language authors to release their languages and engines under
> their desired licenses, since we do not force them to submit the
> engine into BSF under the ASF license.
>
> Beyond that, I think the CodeBuffer needs fleshing out, and error
> reporting needs improvement - rather than a full blown debug
> interface.
>
> A few other desired features come to mind. However, this covers
> the majority of what I consider to be the direction BSF needs to
> be sailing.
Sounds great. If we get going on some of these I'm quite certain
we will attract a vibrant community for this project. I will be
happy to do what I can!
Sanjiva.
Re: re-organizing the BSF source tree
Posted by "Victor J. Orlikowski" <vj...@dulug.duke.edu>.
On Wed, May 07, 2003 at 01:13:09PM +0600, Sanjiva Weerawarana wrote:
> I'd like to re-org the src tree. Are there any willing helpers?
> I think we need the usual structure:
>
> jakarta-bsf/
> src/
> samples/
> lib/
> [whatever other stuff at the top level]
>
> jakarta-bsf/src/
> org/
> apache/
> bsf/
> ...
>
> What's in the taglib, bsf_debug, jsdb directories? How should those
> fit in?
>
My apologies for the late entry into the discussion; it is only
recently that I have been able to resolve some issues related to
this very topic.
Indeed, the source tree needs a complete re-org; I am certainly
willing to help, or do it myself if no one else beats me to it
(and no one objects to my stance on the issue).
These are my thoughts on the issue:
1) bsf_debug and jsdb need to go. The debug interface, as it
currently exists, is shameful, in performance and usefulness.
2) The taglib directory also needs to go. With JSP 2.0 upcoming, I
believe that BSF has a limited role, if any, in JSPs - EL does a
*much* better job in its place. The taglib in this source tree was
a modification to support the aforementioned debug interface.
Hence, it needs to go. I would argue that the currently existing
BSF taglibs (in the taglibs project) need killing too, based on
the my belief that BSF and JSPs really shouldn't mix (performance
is abysmal, confusion stemming from having two separate contexts
in the form of the generated servlet and the language engine
executing script code within it, etc.)
3) Debug hooks need to be ripped out of the original BSF source,
and we thereby return to the code as it was in 2.2, modulo some
bugfixes.
As to what should be in the source before another release passes
us, is a means, as suggested around January, for languages to be
auto-detected at runtime, so that we do not have to incorporate
every language engine under the sun into BSF. This makes life
easier from a maintenance standpoint, as well as permitting
language authors to release their languages and engines under
their desired licenses, since we do not force them to submit the
engine into BSF under the ASF license.
Beyond that, I think the CodeBuffer needs fleshing out, and error
reporting needs improvement - rather than a full blown debug
interface.
A few other desired features come to mind. However, this covers
the majority of what I consider to be the direction BSF needs to
be sailing.
Victor
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
==================================================================
orlikowski@apache.org | vjo@dulug.duke.edu | vjo@us.ibm.com
Re: re-organizing the BSF source tree
Posted by Chuck Murcko <ch...@topsail.org>.
On Wednesday, May 7, 2003, at 00:13 America/Phoenix, Sanjiva
Weerawarana wrote:
> It seems to me that the BSF src tree can stand some re-org.
> For example, to get to the src currently you have to go to:
>
> jakarta-bsf/src/bsf-2.3/bsf/src/org/apache/bsf
>
> Note that that path has "bsf" and "src" repeated .. not good.
> Also, I haven't yet found the samples ..
>
> I'd like to re-org the src tree. Are there any willing helpers?
> I think we need the usual structure:
>
> jakarta-bsf/
> src/
> samples/
> lib/
> [whatever other stuff at the top level]
>
> jakarta-bsf/src/
> org/
> apache/
> bsf/
> ...
>
> What's in the taglib, bsf_debug, jsdb directories? How should those
> fit in?
>
That sounds great - it was something I knew was needed before I dropped
the original code.
The taglib directory is an updated BSF taglib that should go over to
the Jakarta taglib project. I can contact about that.
The bsf_debug and jsdb directories are a Javascript JSP debugger API
and line debugger (for checking the API). Their future looks uncertain.
We'll also need to accommodate unit testers (junit) in this directory
structure.
Chuck