On Mon, Jun 16, 2003 at 10:48:26PM +0600, Sanjiva Weerawarana wrote: > "Bill Stoddard" <[EMAIL PROTECTED]> 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! ================================================================== [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
