Mike, just FYI on that issue last week..... no need for you to be
paranoid!
......... it turns out that "-
WOAllowsConcurrentRequestHandling=true" is the incorrect syntax.
Here is the problem summary:
Root cause:
The presence of an invalid property format in WOMonitor resulting in
subsequent launch arguments not being set properly. Notably we
noticed the result of the WOFrameworksBaseURL command line property
not being set, which happens to be the last launch argument in the
woa launch shell script, to not be set.
Incorrect Syntax: -WOAllowsConcurrentRequestHandling=true
Solution:
Correct Syntax: -WOAllowsConcurrentRequestHandling true (Note the
absence of "=")
OR
-DWOAllowsConcurrentRequestHandling=true
Both forms of the correct syntax work, but beware of one incorrect
syntax property making the subsequent properties ineffective.
Regards, Kieran
On Dec 7, 2007, at 5:08 PM, Mike Schrag wrote:
> That's insanity ... I would double-check that _WOIDEProject isn't
> screwing with you ... Now I'm just paranoid.
>
> ms
>
> On Dec 7, 2007, at 4:50 PM, Kieran Kelleher wrote:
>
>> This has me puzzled ..... just asking if anyone has seen this before:
>>
>> I deploy fully embedded builds which normally works fine, however
>> when concurrent request handling is turned on via launch args in
>> WOMonitor app config, the app seems to ignore the -
>> WOFrameworksBaseURL argument and proceeds to render all resource
>> URLs to default frameworks locations (and of course they are not
>> there ... they are embedded in the app). Stopping app, removing
>> the -WOAllowsConcurrentRequestHandling=true parameter and
>> relaunching in Monitor and all ws resource URLs work properly again!!
>>
>> Any ideas?
>>
>> App was built with today's WOLips and Wonder is a week old. All
>> deployed on WO 5.3.3 on Tiger server.
>>
>>
>> Regards, Kieran
>>
>>
>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Mon Dec 10 2007 - 16:49:10 EST