[Laszlo-dev] For Review: Change 20080904-hqm-J Summary: call flex compiler classes directly from jar file

[Henry Minsky]

Looking at the flex compiler code, there are a bunch of other state vars
that I don't haveany idea what they do, and which all use this ThreadLocal
mechanism:

public final class ThreadLocalToolkit
{

    private static ThreadLocal<Logger> logger = new ThreadLocal<Logger>();
    private static ThreadLocal<PathResolver> resolver = new
ThreadLocal<PathResolver>();
    private static ThreadLocal<Map<String, VirtualFile>> resolved = new
ThreadLocal<Map<String, VirtualFile>>();
    private static ThreadLocal<Benchmark> stopWatch = new
ThreadLocal<Benchmark>();
    private static ThreadLocal<LocalizationManager> localization = new
ThreadLocal<LocalizationManager>();
    private static ThreadLocal<MimeMappings> mimeMappings = new
ThreadLocal<MimeMappings>();
    private static ThreadLocal<ProgressMeter> progressMeter = new
ThreadLocal<ProgressMeter>();
    private static ThreadLocal<CompilerControl> compilerControl = new
ThreadLocal<CompilerControl>();
    private static ThreadLocal<StandardDefs> standardDefs = new
ThreadLocal<StandardDefs>();

So I'm thinking to be safe maybe I had better make sure each invocation of
the
flex compiler is inside of a new thread.


On Thu, Sep 4, 2008 at 10:40 PM, Donald Anderson <dda at ddanderson.com> wrote:

> Yes, I would think tomcat would have a thread pool.But -- actually if you
> look at the function, I don't think exitval
> is actually used for anything important, so that call could be removed.
> The state of the compilation is measured by whether the output file is
> produced.
>
> On Sep 4, 2008, at 8:44 PM, Henry Minsky wrote:
>
> Maybe I should have the callJavaCompileCommand method call the flex
> compilerin a new thread??
>
>
>
> On Thu, Sep 4, 2008 at 8:43 PM, Henry Minsky <hminsky at laszlosystems.com>wrote:
>
>>
>>>
>>> 2)
>>> +        exitval = flex2.compiler.util.ThreadLocalToolkit.errorCount();
>>> Couldn't find any doc for ThreadLocalToolkit.  Are the errors additive,
>>> or will they be reset to 0 on each call into the compiler?  (i.e. I'm
>>> worried about an error being 'sticky' to the next compile - I guess
>>> it would only result in a stray FAIL println to the error console).
>>>
>>
>> The ThreadLocalToolkit class has a flex Logger object, which is stored
>> within a ThreadLocal
>> object, which is a Java thing that creates local vars which are unique to
>> a thread.  The Logger object
>> holds the error count. So as long as each compile is done in a new thread,
>> the error count
>> will get reset. Now, the question is whether each compile actually does
>> happen in a new thread. I
>> bet Tomcat has some kind of a thread pool, so I wonder if this is going to
>> cause confusion
>> at some point.
>>
>>
>>
>>
>>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
>
>
>
> --
>
> Don Anderson
> Java/C/C++, Berkeley DB, systems consultant
>
> voice: 617-547-7881
> email: dda at ddanderson.com
> www: http://www.ddanderson.com
>
>
>
>


-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20080904/33084f90/attachment.html