Re: 404 from onActivate

2010-03-20 Thread Jan Jirout 

Hi,

thanks for replay. My situation is exactly as you wrote. After all this 
approach works just in case of Jetty. It doesn't work with Tomcat 6.0.20 
and 6.0.24. I have tested it. Only difference between processing page 
that should lead to error404 is that at tomcat page processing continue 
after error 404 in send, so there appears some NullPointerExceptions. I 
don't see this exception at Jetty.


Jan


Kalle Korhonen wrote:

If you want Tapestry to render your error page, you need to configure
the filter to handle error dispatches:

app
/*
REQUEST
ERROR


Entirely possible that Jetty would route this to the app by default
but I think it's off-spec.

Kalle


On Fri, Mar 19, 2010 at 2:50 PM, Jan Jirout  wrote:
  

Hi,

I have same problem. I don't like solution with HTTP redirect to page that
return 404 also. This solution is not fully logic from user perspective. I
would like to by able to show error404 without any redirect.

I have tried in onActivation method code:

response.sendError(404, null);

where:

  @Inject
  private org.apache.tapestry5.services.Response response;

It works in jetty, but didn't work in Tomcat ;-). I hope, that somebody will
help.

Regards

Jan

Igor Drobiazko wrote:


Just inject service RequestGlobals [1] into your page, retrieve the
Response
from it and send the 404 error to the client.

[1]

http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/services/RequestGlobals.html

On Fri, Mar 19, 2010 at 6:39 PM, Mike Oestereter
wrote:


  

That's what I'm doing at the moment, but is not what I want.
The result from the user's perspective is is a redirect 302 (or
something) to a 404, which I don't think makes sense?

On Fri, Mar 19, 2010 at 4:51 PM, Christian Riedel
 wrote:



I would create an Error404.java page and redirect to it in case your

  

onActivate doesn't find a corresponding entity.



Am 19.03.2010 um 15:04 schrieb Mike Oestereter:


  

Hello

I've got a page that takes the context as parameter to produce a
result from db, e.g.:  http:/hostname/app/page/123

If the db result for 123 does not exist I would like to throw a 404.

Currently I'm using...

Object onActivate(EventContext context) {
 //db lookup code to prepare page
}

Is the best way to throw a custom error that gets picked up by the
ExceptionReport page and "rendered" with a status code of 404?

Or is there a way to initialize/prepare the page earlier in the cycle
and detect the non existence of resource 123?

Thanks
Theo

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org



  

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org






  

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org


  



-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: 404 from onActivate

2010-03-19 Thread Jan Jirout 

Hi,

I have same problem. I don't like solution with HTTP redirect to page 
that return 404 also. This solution is not fully logic from user 
perspective. I would like to by able to show error404 without any redirect.


I have tried in onActivation method code:

response.sendError(404, null);

where:

   @Inject
   private org.apache.tapestry5.services.Response response;

It works in jetty, but didn't work in Tomcat ;-). I hope, that somebody 
will help.


Regards

Jan

Igor Drobiazko wrote:

Just inject service RequestGlobals [1] into your page, retrieve the Response
from it and send the 404 error to the client.

[1]
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/services/RequestGlobals.html

On Fri, Mar 19, 2010 at 6:39 PM, Mike Oestereter
wrote:

  

That's what I'm doing at the moment, but is not what I want.
The result from the user's perspective is is a redirect 302 (or
something) to a 404, which I don't think makes sense?

On Fri, Mar 19, 2010 at 4:51 PM, Christian Riedel
 wrote:


I would create an Error404.java page and redirect to it in case your
  

onActivate doesn't find a corresponding entity.


Am 19.03.2010 um 15:04 schrieb Mike Oestereter:

  

Hello

I've got a page that takes the context as parameter to produce a
result from db, e.g.:  http:/hostname/app/page/123

If the db result for 123 does not exist I would like to throw a 404.

Currently I'm using...

Object onActivate(EventContext context) {
 //db lookup code to prepare page
}

Is the best way to throw a custom error that gets picked up by the
ExceptionReport page and "rendered" with a status code of 404?

Or is there a way to initialize/prepare the page earlier in the cycle
and detect the non existence of resource 123?

Thanks
Theo

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org


  

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org






  



-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

problems with page testing

2010-02-15 Thread Jan Jirout 

Hi,

I would like to ask about your testing practice. I have few problem with 
testing. Now I have simple T5 application with few pages and forms.


1) When I write page it's straightforward process I create components 
and then compose from them page. But when I write test for one page for 
each page component I have to write mock. I have to write component mock 
behavior for each component usage. Component mocking is quite talkative. 
T5 is component oriented framework so page is composed from components, 
but testing as it's described in T5 tutorial is one procedure call.


2) When I test page action link and this link point to some page I have 
to mock behavior of this destination page. Or better I can just call 
method that mock behavior of this destination page. It works. But when 
final page is changed than this action link test starts falling even if 
test is correct just destination page is faulty.


Maybe my problem are caused by lack of information, if you know some T5 
testing information I'll appreciated it.


regards
Jan




BTW PageTester class seems to me not fully finished. Method for testing 
links with parameter like "showItem?t:ac=22" is not yet implemented. And 
at line 304 shouldn't be:

   decodeParametersIntoRequest(path.substring(comma + 1));
there should be:
   decodeParametersIntoRequest(linkPath.substring(comma + 1));


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: problem with component

2010-02-04 Thread Jan Jirout 

Hi,

thanks for looking at this, it really helps me. I think that I found 
place where is forForm changed to wrong value, let me describe it:


It seems that LinkImpl is correctly created in 
ComponentEventLinkEncoderImpl at 194 with forForm=true. Next is 
ComponentEventLinkEncoderMethodAdvice#advice called. There is created 
"fakeRequest". This "fakeRequest" is then passed through all registered 
URLRewriterRule implementations and rewrited request is returned. If 
"fakeRequest" and rewritten request are not same then LinkImpl is 
rewritten. This is the place where is the problem, LinkImpl rewriting 
code is:


   newLink = new LinkImpl(newUrl, false, false, response, null);

so the rewritten link have always forForm=false. And this is the problem.

I'll try change implementation of ComponentEventLinkEncoderMethodAdvice, 
it seems to me that it could help. I don't fully understand T5 so I 
don't know if it's bug or not. What do you think?


regards

Jan


Josh Canfield wrote:

I should add that

  

SimpleRequestWrapper fakeRequest = new SimpleRequestWrapper(request,
link.toAbsoluteURI());



comes from ComponentEventLinkEncoderMethodAdvice#rewriteIfNeeded

On Mon, Feb 1, 2010 at 9:20 PM, Josh Canfield  wrote:
  

Ok, I found the problem.
The form action is created like so:
void beginRender(MarkupWriter writer)
   {
   Link link =
resources.createFormEventLink(EventConstants.ACTION, context);

It then pulls the query parameters from the link and sticks them into
hidden fields. The problem is that when you rewrite a url the first
thing it does is converts the link toAbsoluteURI

SimpleRequestWrapper fakeRequest = new SimpleRequestWrapper(request,
link.toAbsoluteURI());

which drops the containing the page context (t:ac) because it's in the
links parameters, and the link is for a form.
From LinkImpl:
private String buildURI()
   {
   if (forForm || parameters == null)
   return absoluteURI;
...


So, the form is built without the page context...

Seems mildly suspicious that the link knows it's for a form. The
javadoc says: "Query parameters are never added to a forForm link."
But I'm not coming up with a good reason why... if the form want's to
treat the query params special then shouldn't it strip them off?

Josh



On Sun, Jan 31, 2010 at 5:45 AM, Jan Jirout  wrote:


Hi,

This is really code that I'm running. I really hope that I'm not wrong about
that. Code that I posted shouldn't affected result of filter. I'm using
tapestry version 5.1.0.5. I added simple project demonstrating the problem.

In attachment is example application demonstrating that SimpleRequestWrapper
in my case somehow change the request.

Let me closely describe used use case. I have component Discussion, this
discussion is used at different king of pages. In object Discussion there
should be inject object implementing ActionRemote. When user submit new
comment is called ActionRemote.onAction(CommentForm form). Injecting of
concrete ActionRemote implementation is done in main page (User) during
executing onActivate phase.

In attached example, there are two ways how to demonstrate problem:
   * start application by "mvn jetty:run" and then access User page and
submit filled form. And you'll see exception saying that page context is
missing.
   * try to run test case UserTest.testSubmitForm() and you'll see same
exception

I hope, that attached example will works in yours environment. Please try to
look at my example, it's possible that I doing something wrong.

Jan

Josh Canfield wrote:
  

I tried to use following code:

  public Request process(Request request, URLRewriteContext context) {
  return new SimpleRequestWrapper(request, request.getPath());
  }

When I use this code then context of component event is even lost. I
didn't
find way how to create SimpleRequestWrapper with component even context.

  

This is surprising. I hate to ask, but are you really sure this is the
code that is running? What you have here should be the equivalent to
doing nothing. What version of tapestry are you using?


Josh

On Sat, Jan 30, 2010 at 2:56 PM, Jan Jirout  wrote:



Hi,

thanks for answer.

In my real application I change just pieces of path but it didn't work.

I tried to use following code:

  public Request process(Request request, URLRewriteContext context) {
  return new SimpleRequestWrapper(request, request.getPath());
  }

When I use this code then context of component event is even lost. I
didn't
find way how to create SimpleRequestWrapper with component even context.

Just in case when I call "return request;" from "process" method is
component event context correctly passed.

If you would like to see example application I can send it to conference.

regards

Jan


Thiago H. de Paula Figueiredo wr

Re: problem with component

2010-01-30 Thread Jan Jirout 

Hi,

thanks for answer.

In my real application I change just pieces of path but it didn't work.

I tried to use following code:

public Request process(Request request, URLRewriteContext context) {
return new SimpleRequestWrapper(request, request.getPath());
}

When I use this code then context of component event is even lost. I 
didn't find way how to create SimpleRequestWrapper with component even 
context.


Just in case when I call "return request;" from "process" method is 
component event context correctly passed.


If you would like to see example application I can send it to conference.

regards

Jan


Thiago H. de Paula Figueiredo wrote:
On Sat, 30 Jan 2010 19:58:34 -0200, Jan Jirout  
wrote:



Hi All,


Hi!

I have strange problem with URL rewriting. I'm changing path name in 
URLRewriterRule. In following way:


  public Request process(Request request, URLRewriteContext 
context) {

  return new SimpleRequestWrapper(request, "somePath");
  }


The above rule rewrites *all* URLs to "somePath", losing any context 
or query parameters. You should use string manipulation to extract the 
original page name and then replace it with the new page name.


If a request to "/original/1 arrives", your should rewrite it to 
"/new/1". You can use path.replace("/original/", "/new/") to do that, 
for example.





-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

problem with component

2010-01-30 Thread Jan Jirout 

Hi All,

I have strange problem with URL rewriting. I'm changing path name in 
URLRewriterRule. In following way:


 public Request process(Request request, URLRewriteContext context) {
 return new SimpleRequestWrapper(request, "somePath");
 }

It works fine. Problem is with page context in case of component events. 
If component event with some context is passed into previous 
URLRewriterRule then page context is lost. Only way how to avoid this 
problem is following adjustment:


 public Request process(Request request, URLRewriteContext context) {
 if (context.getPageParameters() == null) {
   /**
* it's component event
*/
   return request;
 }
 return new SimpleRequestWrapper(request, "somePath");
 }


In this case component events are not processed so context is preserved. 
Problem is that component event URLs are not adjusted. Even following 
example lost component event context.


 public Request process(Request request, URLRewriteContext context) {
 return new SimpleRequestWrapper(request, request.getPath());
 }

Do you have any clue how to process component events without lost context?

thanks

Jan

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

page name generating

2009-12-08 Thread Jan Jirout 

Hi,

I have two probably related problems.

1) I have business object Article and User and also I have package 
com.myapp.pages. Inside this package are placed pages Article and User. 
Both of them works and contains with business object Article and User. 
It lead to state when I have to fully specify business object package 
name. I woud like to use page names as ArticlePage and UserPage but in 
tml file use refference to them as "user" and "article"


2) I have page class files like createNewUser.java and template 
createNewUser.tml. When I access this page URL is "createnewnser" but I 
would like to see URL "create-new-user".


I think that both problems are related to "name stripping", but I don't 
know how to add new rules to this process. It seems to me, that "URL 
rewriting" doesn't help at all.


thanks for help

Jan

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: T5 returns garbage !?

2009-12-03 Thread Jan Jirout 

Hi,

I had the same when I generate images. Images was created by class 
implementing org.apache.tapestry5.services.Dispatcher. I forgot to 
properly close output stream and it sometimes caused same error.


Jan

Gunnar Eketrapp wrote:

That did the trick!

Super Thank You!

/Gunnar

2009/12/3 ningdh 

  

I got this issue in tomcat6+enable gzip option.

But in tomcat5.5, even gzip was enabled, it worked fine.

I suggest you disable the gzip option.

DH
- Original Message -
From: "Gunnar Eketrapp"
To: "Tapestry users" 
Sent: Thursday, December 03, 2009 8:42 PM
Subject: T5 returns garbage !?




Hi!

Sometimes our pages returns totally garbage.

When reloading the page it usually works and the page is delivered fine.

The T5 app runs inside a Tomcat 5.5 app server in a linux evironment.

Has anyone else encountered the same problem?

Thanks in advance,
Gunnar Eketrapp



��� �=P���IUxj�=���u���y��pw� �o�G� <���~}��g�
6}�^��uz���q�  ���ϯG��<��D��!�͍�~"<�H��R��� d�S ��D�2��J�R�%"�  �� ,�`G
+M��(�e��$3ؓ #-H �T�� ؍bkP:�I� LmyyQZq�ɶТ5��� �_h� U��xv|� MI�
cM ��MZ��Bls��P�� b�pO� ][n�  Ǖq  *&@� �q\��>٬��7�?&�
\�H �O`�r� �!��ԕ�O��(CI�E�J%�'W��N/ܿ�n�L��Q� �b�3�^fҝ�;�b�If�'.��
�_aݤ�ʌ�xq�Xv} �� ~nxW�3\�  )v��1聑 �T���~eK��R^�h� <� �{j3�C�>�� A
 |�/�p�7��U$�zj���h�� ?k��F�"/V� #�B?�G��Hg��6"�q_�' Te�_�ҁ�t �
  

Qu)kLq�Ttؔ� ���E U� ;�T��A  �h��� G�6�,&


�ޱ ] a���  ��A S1[ �y�=�) H���-&�J��� l"֋�    �g ��g ��4�f�:��
  

%$� ��+ـy �J


�� p,%�1T  �0� � |U��� |�N^�%�5 #��C� H��/b�H�6 �Pr pܠ
��hM͌wEG��{�P�b<�r2Y.on �_y%Y�_k; ~y߫om�

  




  



-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Problem with property expressions

2009-12-02 Thread Jan Jirout 

Hi,

I would like to that you and Gunnar Eketrapp for help. It works for me now.

thanks

Jan


Thiago H. de Paula Figueiredo wrote:
Em Wed, 02 Dec 2009 08:32:31 -0200, Jan Jirout  
escreveu:



Hi,


Hi!


I have problem with property expression. When I try to use:
//


Never use ${} when passing parameters, as it converts its value to a 
String. In this case, you needed a List.





-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Problem with property expressions

2009-12-02 Thread Jan Jirout 

Hi,

I have problem with property expression. When I try to use:

   //


I expect that result context will be string like "orderdetail/3/2". But 
result URL is following:

/
/

   /http://localhost:8080/orderdetail/$005b223$002c$00201$005d/


Context contains encoded sign like '[', ']' and ','. If I understand 
specification of property expressions at 
http://tapestry.apache.org/tapestry5.1/guide/propexp.html says than I 
use valid format of context. I would like to use composite page link 
context because I would like to have nice URL.


Can you please suggest me how to use more that one parameters in page 
context.


regards

Jan

Re: T5 Random Issue

2009-11-02 Thread Jan Jirout 

Hi,

I had same problem. I generate images manually by dispatcher. This  
happen when I sometimes didn't close output stream.


regards Jan

On Nov 2, 2009, at 5:34 PM, Carl Crowder wrote:

I have no idea. My vague guess is that the browser isn't unzipping  
the GZipped content for some reason - perhaps the content type is  
wrong? That wouldn't explain why it was intermittent though. Perhaps  
pipe the output through gunzip to see if it decompresses?


Norman Franke wrote:
Periodically, users get pages full of unicode or something like  
this the attached. It displays as boxed question marks in safari.  
This happens in both Safari and Firefox. Refreshing generally  
displays the page properly. What causes this? It's using Tapestry  
5.1.0.5 and Tomcat.
���v7�&��)bxf��V$��ՃK�n� 
$ 
� 
� 
d�W��`2D��̤�B��5t^�<��vd��X�&�h�] 
e�*�Jf`_�occOӋ�U���xX<�>n? 
L���z���V~�����.�&/ 
vg�n0�ڪ�l�[[ggg�gjs<9�z�|�- 
�"��l�?��?�߸w�p4�����ⱍ 
{�{�6���q;k��x4kG�o7f���} 
�bp�L��  
s5�ڟ���˯���I�^��  
45 
� 
f 
� 
� 
^ 
� 
� 
ų 
�xz�f�b�H���x�̺�;�nG�q���Q 
{~6��O�k�;

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Problem with error404

2009-10-07 Thread Jan Jirout 

Hi again,

thanks for help. I have look at bug report that you have entered (https://issues.apache.org/jira/browse/TAP5-879 
).


I have tested it. When I don't have "onActivate" method in my  
Index.java file and user tries access not existing page then Index is  
normally shown. Maybe it could be added to bug description.


Another problem for me was inconsistent behavior of raising exception.  
When I call "response.sendError(404, null);" in my Index.onActivate 
(String pageUrl) it throws an exception. This exception is thrown just  
on Tomcat version 6. It works correctly at jetty and Tomcat 5  
(confirmed by Kalle). From my point of view it's a bug. My working  
environment is described in my first email.


How do you handle "page not found" event?

thanks

Jan


On Oct 7, 2009, at 3:44 PM, cordenier christophe wrote:


Thanks, I did it.

2009/10/7 Thiago H. de Paula Figueiredo 

Em Wed, 07 Oct 2009 10:17:09 -0300, Robin Komiwes  


escreveu:

I must agree with Christophe. With the current behavior, you are  
not able

to distinguish a page that doesn't exist.
Kalle


Please post a JIRA about it.

--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago


-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Problem with error404

2009-10-07 Thread Jan Jirout 

Hi,

It seems that it works like this. If you access not existing page http://localhost/demo/bla 
 it's translated in to http://localhost/demo/index/blah. I think that  
it's default behavior.


Jan


On Oct 7, 2009, at 10:24 AM, cordenier christophe wrote:


Hi

From my humble point of view, using the activate method to send an  
error

when page doesn't exist is not the right place. Imagine that you have
subpackage with there own index page, you will have to duplicate  
your code.


But your question is really pertinent, and I had a closer look at the
ComponentEventLinkEncoder service which is used to identify pages  
during

request dispatch. And it makes me ask another question :

Why an URL like http://localhost/demo/blah (where demo is the  
context) is

translated http://localhost/demo/index/blah where 'blah' become the
activation context of the index even if there there is no activation  
method

?

Does it mean that since we have an index page in our application,  
404 will

never be thrown automatically ?

Christophe.

2009/10/6 Kalle Korhonen 


Don't think I can help you much, but I can verify the same sendError
and error configurations work for me on Tomcat 5.5 (haven't tried on
Tomcat 6).

Kalle


On Tue, Oct 6, 2009 at 3:05 AM, Jan Jirout 
wrote:

Hi All,

I'm playing some time with t5. I have meet simple problem. I hope  
that

it's

not my fault.

So.

I would like to handle "Error 404" in my application so I have in

web.xml:


  
  app
  /*
  REQUEST
  ERROR
  

  
  404
  /error404
  


My Index.java is:


  void onActivate(final String pageUrl) throws IOException {
  if (isKnownPage(pageUrl)) {
  //show page
  } else {
   response.sendError(404, null);
  }
  }

If I access page "/hello"  then pageUrl property is "hello". If  
there is
page /hello then this page is normally processed. If I sendError  
then

page
error404 should be shown. This Error page exists. So when I  
access /blah
then /error404 page is shown. It works fine with jetty. But it  
doesn't

work

with tomcat 6.

I have tried to debug it, and it seems to me, that information about

content
type is lost. In class BufferedGZipOutputStream is already  
information

about
content type lost but in class PageResponseRendererImpl is still  
present.


thanks for help

Jan



Here is my stack trace:
SEVERE: Servlet.service() for servlet default threw exception
java.lang.NullPointerException
  at

org.apache.tapestry5 
.internal.services.ResponseCompressionAnalyzerImpl.isCompressable 
(ResponseCompressionAnalyzerImpl.java:65)

  at

$ResponseCompressionAnalyzer_1241954ff2c.isCompressable 
($ResponseCompressionAnalyzer_1241954ff2c.java)

  at

org.apache.tapestry5 
.internal.gzip.BufferedGZipOutputStream.openResponseOutputStream 
(BufferedGZipOutputStream.java:77)

  at

org.apache.tapestry5 
.internal.gzip.BufferedGZipOutputStream.checkForCutover 
(BufferedGZipOutputStream.java:70)

  at

org.apache.tapestry5.internal.gzip.BufferedGZipOutputStream.write 
(BufferedGZipOutputStream.java:116)

  at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
  at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263)
  at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106)
  at java.io.OutputStreamWriter.write(OutputStreamWriter.java: 
190)

  at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:111)
  at java.io.BufferedWriter.write(BufferedWriter.java:212)
  at java.io.PrintWriter.write(PrintWriter.java:412)
  at java.io.PrintWriter.write(PrintWriter.java:429)
  at java.io.PrintWriter.print(PrintWriter.java:559)
  at org.apache.tapestry5.dom.Text.toMarkup(Text.java:59)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at org.apache.tapestry5.dom.Document.toMarkup(Document.java: 
163)

  at org.apache.tapestry5.dom.Node.toMarkup(Node.java:80)
  at

org.apache.tapestry5.internal.services.MarkupWriterImpl.toMarkup 
(MarkupWriterImpl.java:57)

  at

org.apache.tapestry5 
.internal.services.PageResponseRendererImpl.renderPageResponse 
(PageResponseRende

Re: Problem with error404

2009-10-06 Thread Jan Jirout 

Hi,

Thanks for reply. It seems to me like work around. You suppose me to  
change place where I detect that page can't be found to different  
one.  When I place this logic of detecting invalid page in filer then  
I'll do this work two times. Once time in filter and second time I'll  
examine the requested path in Index.java.


Maybe I should reformulate questions:
Is it bug or not. Same code leads in different results at jetty and  
tomcat?

How you handle invalid page requests?

thanks for any help

Jan


On Oct 6, 2009, at 12:45 PM, cordenier christophe wrote:


Hello

Have you tried with a ComponenRequestFilter instead ?

Christophe

2009/10/6 Jan Jirout 


Hi All,

I'm playing some time with t5. I have meet simple problem. I hope  
that it's

not my fault.

So.

I would like to handle "Error 404" in my application so I have in  
web.xml:


  
  app
  /*
  REQUEST
  ERROR
  

  
  404
  /error404
  


My Index.java is:


  void onActivate(final String pageUrl) throws IOException {
  if (isKnownPage(pageUrl)) {
  //show page
  } else {
   response.sendError(404, null);
  }
  }

If I access page "/hello"  then pageUrl property is "hello". If  
there is
page /hello then this page is normally processed. If I sendError  
then page
error404 should be shown. This Error page exists. So when I access / 
blah
then /error404 page is shown. It works fine with jetty. But it  
doesn't work

with tomcat 6.

I have tried to debug it, and it seems to me, that information about
content type is lost. In class BufferedGZipOutputStream is already
information about content type lost but in class  
PageResponseRendererImpl is

still present.

thanks for help

Jan



Here is my stack trace:
SEVERE: Servlet.service() for servlet default threw exception
java.lang.NullPointerException
  at
org.apache.tapestry5 
.internal.services.ResponseCompressionAnalyzerImpl.isCompressable 
(ResponseCompressionAnalyzerImpl.java:65)

  at
$ResponseCompressionAnalyzer_1241954ff2c.isCompressable 
($ResponseCompressionAnalyzer_1241954ff2c.java)

  at
org.apache.tapestry5 
.internal.gzip.BufferedGZipOutputStream.openResponseOutputStream 
(BufferedGZipOutputStream.java:77)

  at
org.apache.tapestry5 
.internal.gzip.BufferedGZipOutputStream.checkForCutover 
(BufferedGZipOutputStream.java:70)

  at
org.apache.tapestry5.internal.gzip.BufferedGZipOutputStream.write 
(BufferedGZipOutputStream.java:116)

  at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
  at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263)
  at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106)
  at java.io.OutputStreamWriter.write(OutputStreamWriter.java: 
190)

  at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:111)
  at java.io.BufferedWriter.write(BufferedWriter.java:212)
  at java.io.PrintWriter.write(PrintWriter.java:412)
  at java.io.PrintWriter.write(PrintWriter.java:429)
  at java.io.PrintWriter.print(PrintWriter.java:559)
  at org.apache.tapestry5.dom.Text.toMarkup(Text.java:59)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at
org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:840)
  at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
  at org.apache.tapestry5.dom.Document.toMarkup(Document.java: 
163)

  at org.apache.tapestry5.dom.Node.toMarkup(Node.java:80)
  at
org.apache.tapestry5.internal.services.MarkupWriterImpl.toMarkup 
(MarkupWriterImpl.java:57)

  at
org.apache.tapestry5 
.internal.services.PageResponseRendererImpl.renderPageResponse 
(PageResponseRendererImpl.java:67)

  at
$PageResponseRenderer_1241954ff57.renderPageResponse 
($PageResponseRenderer_1241954ff57.java)

  at
org.apache.tapestry5 
.internal.services.DefaultRequestExceptionHandler.handleRequestException 
(DefaultRequestExceptionHandler.java:77)

  at
$RequestExceptionHandler_1241954ff38.handleRequestException 
($RequestExceptionHandler_1241954ff38.java)

  at
org.apache.tapestry5.internal.services.RequestErrorFilter.service 
(RequestErrorFilter.java:42)

  at
$RequestHandler_1241954ff3a.service($RequestHandler_1241954ff3a.java)
  at
org.apache.tapestry5.services.TapestryModule$4.service 
(TapestryMo

Problem with error404

2009-10-06 Thread Jan Jirout 

Hi All,

I'm playing some time with t5. I have meet simple problem. I hope that  
it's not my fault.


So.

I would like to handle "Error 404" in my application so I have in  
web.xml:



app
/*
REQUEST
ERROR



404
/error404



My Index.java is:


void onActivate(final String pageUrl) throws IOException {
if (isKnownPage(pageUrl)) {
//show page
} else {
 response.sendError(404, null);
}
}

If I access page "/hello"  then pageUrl property is "hello". If there  
is page /hello then this page is normally processed. If I sendError  
then page error404 should be shown. This Error page exists. So when I  
access /blah then /error404 page is shown. It works fine with jetty.  
But it doesn't work with tomcat 6.


I have tried to debug it, and it seems to me, that information about  
content type is lost. In class BufferedGZipOutputStream is already  
information about content type lost but in class  
PageResponseRendererImpl is still present.


thanks for help

Jan



Here is my stack trace:
SEVERE: Servlet.service() for servlet default threw exception
java.lang.NullPointerException
at  
org.apache.tapestry5 
.internal.services.ResponseCompressionAnalyzerImpl.isCompressable 
(ResponseCompressionAnalyzerImpl.java:65)
at $ResponseCompressionAnalyzer_1241954ff2c.isCompressable 
($ResponseCompressionAnalyzer_1241954ff2c.java)
at  
org.apache.tapestry5 
.internal.gzip.BufferedGZipOutputStream.openResponseOutputStream 
(BufferedGZipOutputStream.java:77)
at  
org.apache.tapestry5 
.internal.gzip.BufferedGZipOutputStream.checkForCutover 
(BufferedGZipOutputStream.java:70)
at  
org.apache.tapestry5.internal.gzip.BufferedGZipOutputStream.write 
(BufferedGZipOutputStream.java:116)

at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java: 
190)

at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:111)
at java.io.BufferedWriter.write(BufferedWriter.java:212)
at java.io.PrintWriter.write(PrintWriter.java:412)
at java.io.PrintWriter.write(PrintWriter.java:429)
at java.io.PrintWriter.print(PrintWriter.java:559)
at org.apache.tapestry5.dom.Text.toMarkup(Text.java:59)
at org.apache.tapestry5.dom.Element.writeChildMarkup 
(Element.java:840)

at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
at org.apache.tapestry5.dom.Element.writeChildMarkup 
(Element.java:840)

at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
at org.apache.tapestry5.dom.Element.writeChildMarkup 
(Element.java:840)

at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
at org.apache.tapestry5.dom.Element.writeChildMarkup 
(Element.java:840)

at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
at org.apache.tapestry5.dom.Element.writeChildMarkup 
(Element.java:840)

at org.apache.tapestry5.dom.Element.toMarkup(Element.java:356)
at org.apache.tapestry5.dom.Document.toMarkup(Document.java: 
163)

at org.apache.tapestry5.dom.Node.toMarkup(Node.java:80)
at  
org.apache.tapestry5.internal.services.MarkupWriterImpl.toMarkup 
(MarkupWriterImpl.java:57)
at  
org.apache.tapestry5 
.internal.services.PageResponseRendererImpl.renderPageResponse 
(PageResponseRendererImpl.java:67)
at $PageResponseRenderer_1241954ff57.renderPageResponse 
($PageResponseRenderer_1241954ff57.java)
at  
org.apache.tapestry5 
.internal.services.DefaultRequestExceptionHandler.handleRequestException 
(DefaultRequestExceptionHandler.java:77)
at $RequestExceptionHandler_1241954ff38.handleRequestException 
($RequestExceptionHandler_1241954ff38.java)
at  
org.apache.tapestry5.internal.services.RequestErrorFilter.service 
(RequestErrorFilter.java:42)
at $RequestHandler_1241954ff3a.service 
($RequestHandler_1241954ff3a.java)
at org.apache.tapestry5.services.TapestryModule$4.service 
(TapestryModule.java:778)
at $RequestHandler_1241954ff3a.service 
($RequestHandler_1241954ff3a.java)
at org.apache.tapestry5.services.TapestryModule$3.service 
(TapestryModule.java:767)
at $RequestHandler_1241954ff3a.service 
($RequestHandler_1241954ff3a.java)
at  
org.apache.tapestry5.internal.services.StaticFilesFilter.service 
(StaticFilesFilter.java:85)
at $RequestHandler_1241954ff3a.service 
($RequestHandler_1241954ff3a.java)
at  
org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke 
(CheckForUpdatesFilter.java:90)
at  
org.apache.tapestry5.internal.services.Ch