Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Message-ID: <47C50D23.6060906@apache.org>
Date: Wed, 27 Feb 2008 08:11:31 +0100
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de;
 rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: jetty
References: <47C29EBF.3040109@cc.oulu.fi> <47C3B7F7.7040603@apache.org>
 <47C3D60A.5080208@oulu.fi>
In-Reply-To: <47C3D60A.5080208@oulu.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hmm, from this description I can only guess what the problem might be. I 
guess that you have different libs and/or different class loading 
behaviour between Jetty and Tomcat. So it might be that you end up with 
a different Rhino version used or something similar.

In any case, you should see an exception "somewhere" (being it in the 
browser or in the logs); your description also seems to imply that in 
the case of Jetty an endless loop is reached. So what happens if you set 
finished to true before the loop but leave the try/catch in?

Carsten

Andre Juffer wrote:
> Carsten Ziegeler wrote:
>> Which xml files are you refering to?
> 
> Just my own files (required for a pipeline). If I make a simple typing 
> error in one of these files, jetty simply hangs up and I need to 
> manually kill the process. I would have expected to see an error message 
> plus a trace stack to see where an error occurs.
> 
> I have an example from flow, which goes like (out of my head):
> 
> ...
> var form = new Form(...);
> form.createBinding(...);
> var finished = false;
> var data = new ...;
> while (!finished)
> {
>  try {
>   form.load(data);
>   form.showForm(...)
>   form.save(data);
>   do_something_with(data);
>   finished = true;
>  }
>  catch (ex)
>  {
>     var w = form.lookupWidget("messages");
>     w.addMessage(ex.message);
>  }
> }
> cocoon.sendPage(...);
> 
> So, in this case, there are no errors in any XML file. Jetty apparently 
> cannot 'handle' the 'catch(ex)' part whether or not an exception takes 
> place (the exception is for instance occurring in 
> do_something_with(data) as result of the handling of the data in the 
> domain layer). The catch portion simply ensures that if there is an 
> exception, the error message is displayed to the user. Jetty simply 
> freezes here. If I remove the while, try and catch portion (but keep the 
> lines from 'form.load()' to 'finished=true', everything is fine. If I 
> make a war file and deploy the above to tomcat, there are absolutely no 
> problems. The flow portion above was taken from an application that runs 
> fine with all versions of cocoon+tomcat. I must assume that there is 
> problem caused by Jetty, but I cannot see why that should be. I am 
> running this all on a Linux box (AMD64) with Java 6.
> 
>>
>> Carsten
>>
>> Andre Juffer wrote:
>>> Hi All,
>>>
>>> I am testing a cocoon-based webapp. For this, I use the 'mvn 
>>> jetty:run'. This all works fine, unless there is an error in any of 
>>> the underlying XML files. For instance, if there is a minor error 
>>> like missing an '>' (implying invalid XML), which is just a typing 
>>> error, jetty just hangs up completely and ultimately gives an out of 
>>> memory error exception. If that is not the case, the only way to stop 
>>> jetty is to manually kill the process (on a Linux box). Is there a 
>>> way to get rid of or change this behavior. With cocoon 2.1.* (and 
>>> tomcat), decent error message and stack trace were returned so that 
>>> could figure out the problem. This would be the preferred behavior.
>>>
>>> Thanks,
>>> Andre
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>
>>
> 
> 


-- 
Carsten Ziegeler
cziegeler@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org