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

[Donald Anderson]

Strictly speaking, no there's not a completely portable way, as some  
systems
may not have processes.  But if a system has processes, and 'java' is  
in the command
path, I would think we could bypass the adobe shell scripts by calling
   java -Xmx384m -Dsun.io.useCanonCaches=false -jar ..../compc.jar
Not sure if the classpath is already set in the tomcat environment  
correctly?

I guess this runs the small risk that the adobe shell scripts do  
something more sophisticated
in the future (like set additional java properties), so we'd need to  
eyeball them whenever we upgrade.
We'd probably need to be conscious of such things if we call the  
compiler directly anyway.

On Sep 5, 2008, at 10:46 AM, Henry Minsky wrote:

> So is there a portable way to exec a new Java process? I *think*  
> David's objection was that
> the exec we were doing originally was not portable across all  
> possible java operating system environments.
> Is there a vanilla way in Java to say "exec a new Java process with  
> calling this
> class/method to start, or passing a class which has a main() method?
>
>
>
> On Fri, Sep 5, 2008 at 10:05 AM, Donald Anderson  
> <dda at ddanderson.com> wrote:
> I would tend to agree.  For one thing, it looks like we'd need to  
> configure the java vm for
> tomcat with an extra amount (surely it can't be 300K??) just in case  
> they use the SWF9 compiler.
> If you happen to do development on a machine with 1G or less of  
> physical memory,
> you could have a lot of thrashing.
>
> On Sep 5, 2008, at 4:03 AM, P T Withington wrote:
>
>> At the very least.  I am still campaigning for it to be called in a  
>> separate process because:
>>
>> + The server is a long-running process that has to maintain state
>>
>> + The compiler is a task that does not maintain state from one  
>> invocation to the next
>>
>> Hence the compiler is an excellent candidate for 'unix GC', i.e.,  
>> use a process to reclaim all resources when the task is done.  That  
>> ensures the compiler will not jeopardize the server's uptime.
>>
>> There is the issue of ensuring that the compiler process must run  
>> 'headless' so that it does not throw up a bogus window/task-bar  
>> entry (which is the default thing for a java process to do).
>>
>> On 2008-09-04, at 20:44EDT, 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
>
>


--

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

voice: 617-547-7881
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/20080905/16214f05/attachment-0001.html