You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Andre Juffer <aj...@sun3.oulu.fi> on 2008/02/25 11:55:59 UTC
jetty
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
Re: jetty
Posted by Andre Juffer <An...@oulu.fi>.
Joerg Heinicke wrote:
> On 27.02.2008 08:15, Andre Juffer wrote:
>
>>> Is it only me wondering how this can work at all when there is an
>>> exception? In that case finished is NEVER set to true and you always
>>> get into an infinite loop. How can this work with Tomcat? Or am I
>>> just missing something?
>>
>> If there is an exception, it should be caught by the catch (ex)
>> portion, which extracts the message and puts it in the message form.
>> finished remains false (you are entirely right) and the form is being
>> displayed again to the user as I intended.
>
> If it can display the form ... otherwise you get into the try block
> again, it throws again an exception, catches and handles it, back to try
> block ... and so on. That's what I had in mind.
Ah, I see. Yeah, that could indeed be an issue. I have to mention that I
have used this code in many occasions, and it never seem to have caused
an issue, as I usually check first whether or not the entered data is
valid (I rely on dojo for this purpose).
>
> Joerg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: Andre.Juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
NordProt | WWW: www.nordprot.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.02.2008 08:15, Andre Juffer wrote:
>> Is it only me wondering how this can work at all when there is an
>> exception? In that case finished is NEVER set to true and you always
>> get into an infinite loop. How can this work with Tomcat? Or am I just
>> missing something?
>
> If there is an exception, it should be caught by the catch (ex) portion,
> which extracts the message and puts it in the message form. finished
> remains false (you are entirely right) and the form is being displayed
> again to the user as I intended.
If it can display the form ... otherwise you get into the try block
again, it throws again an exception, catches and handles it, back to try
block ... and so on. That's what I had in mind.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Andre Juffer <An...@oulu.fi>.
>Carsten Ziegeler wrote:
> Andre Juffer wrote:
>>
> Now, I agree with Joerg that this code looks very suspicious; I guess
> your intention is to catch an exception while dealing with the data in
> "do_something_with(data)".
Correct.
> The problem with the code above is that if an
> exception occurs in form.load() or form.showForm() etc. you end up with
> an endless loop.
> So I would rather catch the exception inside the "do_xxx" method (or
> handle error codes in a more graceful way than just catching exceptions).
Yeah, I guess this is what I need to do then. There is in fact an
exception handling mechanism in do_xxx(). I will improve this then.
>
> Although I suggest to improve the code, I fear that this is not the
> cause of your problem. My guess is still a class loader issue: you might
> end up with different libs being used in Jetty.
OK, let's assume that this is the case. There is probably not much that
I can do about it.
I'll follow the suggestion by Joerg and you to handle these exception
occuring in do_xxx() in a different way.
Thanks.
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: Andre.Juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
NordProt | WWW: www.nordprot.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
Andre Juffer wrote:
> Joerg Heinicke wrote:
>> On 26.02.2008 04:04, Andre Juffer wrote:
>>
>>> 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(...);
>>
>> Is it only me wondering how this can work at all when there is an
>> exception? In that case finished is NEVER set to true and you always
>> get into an infinite loop. How can this work with Tomcat? Or am I just
>> missing something?
>
> If there is an exception, it should be caught by the catch (ex) portion,
> which extracts the message and puts it in the message form. finished
> remains false (you are entirely right) and the form is being displayed
> again to the user as I intended. If there is no exception, finished is
> set to true and the while loops ends. The script ends with the
> cocoon.sendPage(). This has worked fine with tomcat. Maybe I am too much
> of Java programmer such that I miss certain things in Javascript.
>
Now, I agree with Joerg that this code looks very suspicious; I guess
your intention is to catch an exception while dealing with the data in
"do_something_with(data)". The problem with the code above is that if an
exception occurs in form.load() or form.showForm() etc. you end up with
an endless loop.
So I would rather catch the exception inside the "do_xxx" method (or
handle error codes in a more graceful way than just catching exceptions).
Although I suggest to improve the code, I fear that this is not the
cause of your problem. My guess is still a class loader issue: you might
end up with different libs being used in Jetty.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Andre Juffer <An...@oulu.fi>.
Joerg Heinicke wrote:
> On 26.02.2008 04:04, Andre Juffer wrote:
>
>> 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(...);
>
> Is it only me wondering how this can work at all when there is an
> exception? In that case finished is NEVER set to true and you always get
> into an infinite loop. How can this work with Tomcat? Or am I just
> missing something?
If there is an exception, it should be caught by the catch (ex) portion,
which extracts the message and puts it in the message form. finished
remains false (you are entirely right) and the form is being displayed
again to the user as I intended. If there is no exception, finished is
set to true and the while loops ends. The script ends with the
cocoon.sendPage(). This has worked fine with tomcat. Maybe I am too much
of Java programmer such that I miss certain things in Javascript.
>
> Joerg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: Andre.Juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
NordProt | WWW: www.nordprot.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Joerg Heinicke <jo...@gmx.de>.
On 26.02.2008 04:04, Andre Juffer wrote:
> 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(...);
Is it only me wondering how this can work at all when there is an
exception? In that case finished is NEVER set to true and you always get
into an infinite loop. How can this work with Tomcat? Or am I just
missing something?
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
Carsten Ziegeler wrote:
>> If I replace 'var finished = false' to 'var finished = true', the
>> while portion is skipped and the script continues with
>> cocoon.sendPage(...).
>>
> :)
>
> True, but you can set finished to true as the first statement in the
> while loop.
>
OK. I tried. After completing the form and hitting submit, I get the
infinite loop once more. Jetty seems to run forever and there are no
message placed into the log. Very odd all.
I should note that I can actually do 'Control-C' in the shell that runs
'mvn jetty-run' and I get
2008-02-27 09:51:04.036::INFO: Shutdown hook executing
2008-02-27 09:51:05.192:/:INFO: Closing Spring root WebApplicationContext
Jetty is still 'closing' ...
Thanks,
--
Andre H. Juffer | Email: Andre.Juffer@oulu.fi
The Biocenter and | WWW: www.biochem.oulu.fi/Biocomputing/
the Dep. of Biochemistry | Fax: +358-8-553-1141
University of Oulu, Finland | Phone: +358-8-553 1161
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
Sorry, I do to correct myself. Placing the 'var finished = false' as the
first statement actually works fine! This I do not understand at all.
Thanks,
Andre
Carsten Ziegeler wrote:
> Andre Juffer schrieb:
>> Carsten Ziegeler wrote:
>>> 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?
>>
>> If I replace 'var finished = false' to 'var finished = true', the
>> while portion is skipped and the script continues with
>> cocoon.sendPage(...).
>>
> :)
>
> True, but you can set finished to true as the first statement in the
> while loop.
>
> Carsten
>
>
--
Andre H. Juffer | Email: Andre.Juffer@oulu.fi
The Biocenter and | WWW: www.biochem.oulu.fi/Biocomputing/
the Dep. of Biochemistry | Fax: +358-8-553-1141
University of Oulu, Finland | Phone: +358-8-553 1161
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
Hi Florian,
thanks for the reply. This is the (somewhat adapted) portion of flow
that works fine with all cocoon 2* version and tomcat:
function something()
{
var form = new Form("definition.xml");
form.createBinding("binding.xml");
var data = new ...;
var finished = false;
while (!finished)
{
try
{
form.load(data);
form.showForm(...);
form.save(data);
do_something_with(data);
finished = true;
}
catch (exception)
{
var w = form.lookupWidget("messages");
w.addMessage(exception.message);
}
}
cocoon.sendPage(...);
}
The idea is to display (domain) errors (other than caused by improper
data entered into the form fields) to the user so that he can correct
the data that he has entered previously into that form. This all works
very fine when the application is deployed to tomcat. When I test this
with jetty ('mvn jetty:run'), however, as soon as there is an exception
in do_something_with, the script enters an seemingly infinite loop. If
you just wait long enough, you get an
Exception in thread "Thread-4" java.lang.OutOfMemoryError: Java heap space
....
My assumption was that the catch() is not working as it should. If I
leave out the while loop completely, the catch() part is not working at
all: any exceptions thrown in 'do_something_with(data)' are NOT caught
and the script simply continues with 'cocoon.sendPage(...)'.
The point is now that all these problems completely disappear as soon as
I deploy the application to tomcat (6.0.16) and use the flowscript
portion as above. I run this all with Cocoon 2.2, Java 1.6.0_03 on an
AMD64 Linux box.
Thanks,
Andre
Dev at weitling wrote:
> Hi Andre,
>
> I assume it doesn't help with the core problem (didn't catch the whole
> thread), but why don't you make a do-while-loop?
>
> var finished = false;
> do {
> ...
> finished = true;
> }
> while (!finished);
>
> Or just break?
> while (true) {
> ...
> break;
> }
>
> Setting finished=true to enter at leats once the loop and setting it to
> false inside looks error-prone.
>
> Bye,
> Florian
>
> Andre Juffer wrote:
>>>
>>> True, but you can set finished to true as the first statement in the
>>> while loop.
>>
>> More testing. With finished to true as the first statement in the
>> while loop, if there is NO exception thrown, the script behaves as one
>> would expect. It continue after the form with the cocoon.sendPage(...)
>> statement.
>>
>> However, if there is an exception thrown, the infinite loop reappears.
>> Jetty (or something else) falters on the catch(ex) {...}.
>>
>> Thanks,
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Andre H. Juffer | Email: Andre.Juffer@oulu.fi
The Biocenter and | WWW: www.biochem.oulu.fi/Biocomputing/
the Dep. of Biochemistry | Fax: +358-8-553-1141
University of Oulu, Finland | Phone: +358-8-553 1161
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Dev at weitling <de...@weitling.net>.
Hi Andre,
I assume it doesn't help with the core problem (didn't catch the whole
thread), but why don't you make a do-while-loop?
var finished = false;
do {
...
finished = true;
}
while (!finished);
Or just break?
while (true) {
...
break;
}
Setting finished=true to enter at leats once the loop and setting it to
false inside looks error-prone.
Bye,
Florian
Andre Juffer wrote:
>>
>> True, but you can set finished to true as the first statement in the
>> while loop.
>
> More testing. With finished to true as the first statement in the
> while loop, if there is NO exception thrown, the script behaves as one
> would expect. It continue after the form with the cocoon.sendPage(...)
> statement.
>
> However, if there is an exception thrown, the infinite loop reappears.
> Jetty (or something else) falters on the catch(ex) {...}.
>
> Thanks,
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
>
> True, but you can set finished to true as the first statement in the
> while loop.
More testing. With finished to true as the first statement in the while
loop, if there is NO exception thrown, the script behaves as one would
expect. It continue after the form with the cocoon.sendPage(...) statement.
However, if there is an exception thrown, the infinite loop reappears.
Jetty (or something else) falters on the catch(ex) {...}.
Thanks,
--
Andre H. Juffer | Email: Andre.Juffer@oulu.fi
The Biocenter and | WWW: www.biochem.oulu.fi/Biocomputing/
the Dep. of Biochemistry | Fax: +358-8-553-1141
University of Oulu, Finland | Phone: +358-8-553 1161
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
Andre Juffer schrieb:
> Carsten Ziegeler wrote:
>> 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?
>
> If I replace 'var finished = false' to 'var finished = true', the while
> portion is skipped and the script continues with cocoon.sendPage(...).
>
:)
True, but you can set finished to true as the first statement in the
while loop.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Andre Juffer <aj...@sun3.oulu.fi>.
Carsten Ziegeler wrote:
> 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?
If I replace 'var finished = false' to 'var finished = true', the while
portion is skipped and the script continues with cocoon.sendPage(...).
>
> 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
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
Andre H. Juffer | Email: Andre.Juffer@oulu.fi
The Biocenter and | WWW: www.biochem.oulu.fi/Biocomputing/
the Dep. of Biochemistry | Fax: +358-8-553-1141
University of Oulu, Finland | Phone: +358-8-553 1161
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
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
Re: jetty
Posted by Andre Juffer <An...@oulu.fi>.
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
>>
>>
>
>
--
Andre H. Juffer | Phone: +358-8-553 1161
The Biocenter and | Fax: +358-8-553-1141
the Dep. of Biochemistry | Email: Andre.Juffer@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
NordProt | WWW: www.nordprot.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
Which xml files are you refering to?
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