[Laszlo-dev] For Review: Change 20081212-dda-V Summary: lzsourceannotations=true now uses backtrace lfc.

[Donald Anderson]

Change 20081212-dda-V by dda at lester.local on 2008-12-12 05:44:02 EST
     in /Users/dda/laszlo/src/svn/openlaszlo/trunk-d
     for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: lzsourceannotations=true now uses backtrace lfc.

New Features:

Bugs Fixed: LPP-7435 (LPS.getLFCname needs to be remodularized),
             https://nexb.laszlosystems.com/trac/main/ticket/741 (LZX:  
Regression in proxied launch)

Technical Reviewer: ptw (pending)
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:
     This change only fixes the reported problem, and does not refactor.
     The technique ended up being: wherever 'backtrace' and 'profile'
     have special argument handling, add the same sort of handling for
     sourceannotations; add another argument to getLFCname to enforce
     that the caller has knowledge about sourceannotations, and put
     the smarts about what to do in getLFCname.

     getLFCname should be remodularized to reduce the proliferation of
     arguments, but there are some challenges to doing this, recorded  
here
     in case someone wants to take up the gauntlet again.
     First, not all the callers to getLFCname have ready access to a
     CompilationEnvironment.  In particular, Canvas calls
     getLFCname - combining information from an original  
CompilationEnvironment
     with canvas attributes (so that debugging can be set on the  
canvas).

     And, while this can be solved (giving Canvas a copy of  
CompilationEnvironment,
     or even just the properties), there are at least two additional  
mysteries that
     need better assessing.

     1) CompilationManager.getInfoXML() calls getLFCname using values
       from the request properties that don't completely line up with
       the properties used either in CompilationEnvironment or
       ResponderCompile.initCMgrProperties ('lzbacktrace' is used in  
initCMgrProperties(),
       'backtrace' is used in getInfoXML()).

     2) ResponderLFC.respondImpl() calls getLFCname using standard  
values
        in CompilationEnvironment (yay!) except that it also consults  
an extra
        request parameter "_canvas_debug" (boo!)

     It didn't seem safe to do refactoring and change these two call  
sites (possibly
     breaking some functionality), and not having these sites changed  
makes
     the refactoring rather less effective.  If I knew how to completely
     test the various namespaces that seem to be in use (whether  
intentional or not),
     I'd be more bold in making a change of this sort.


Tests:
     Regression: {smokecheck,weather,lzpix} x {swf8,swf9,dhtml}
     Functionality: simple app observing libraries loaded via args
           ARGS:                        LFC version:
         (noargs)                     LFCdhtml
         lzbacktrace=true             LFCdhtml-backtrace
         backtrace=true               LFCdhtml
         lzsourceannotations=true     LFCdhtml-backtrace

Files:
M      WEB-INF/lps/server/src/org/openlaszlo/cm/CompilationManager.java
M      WEB-INF/lps/server/src/org/openlaszlo/server/LPS.java
M      WEB-INF/lps/server/src/org/openlaszlo/servlets/responders/ 
ResponderCompile.java
M      WEB-INF/lps/server/src/org/openlaszlo/servlets/responders/ 
ResponderLFC.java
M      WEB-INF/lps/server/src/org/openlaszlo/compiler/ 
CanvasCompiler.java
M      WEB-INF/lps/server/src/org/openlaszlo/compiler/ 
ToplevelCompiler.java
M      WEB-INF/lps/server/src/org/openlaszlo/compiler/Compiler.java
M      WEB-INF/lps/server/src/org/openlaszlo/compiler/Canvas.java

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20081212-dda-V.tar



--

Don Anderson
Java/C/C++, Berkeley DB, systems consultant

voice: 617-306-2057
email: dda at ddanderson.com
www: http://www.ddanderson.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20081212/19bee8cd/attachment.html