You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Andrei Tchijov <an...@tchijov.com> on 2007/10/09 22:48:10 UTC
Using RequestDispatcher.include() outside of Request/Response cycle.
Hi,
I have a valve which detects some events in life-cycle of a web
application ( like successful login/failed login/logout ) and invokes
some configurable JSP page to let it perform some audit auctions
( like putting records in the table which trace access to
application ). It works fine, the only problem is auditing session
timeouts. I can (and do) add session listener, so it is not a
problem to detect that session timed out. The problem is how to
invoke my audit JSP page. RequestDispatcher.include() require Request
and Response objects which are obviously not accessible inside
SessionEvent callback. Should I create some sort of "fake" Request/
Response objects? Can I reuse some Request/Response objects from
earlier (like when valve detected creation of the session)? Audit
JSP page does NOT produce any output and it does NOT require any
information from Request, so this Request/Response objects only need
to be able to make RequestDispatcher.include() happy.
Your thoughts will be highly appreciated,
Andrei Tchijov
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using RequestDispatcher.include() outside of Request/Response
cycle.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrei,
Andrei Tchijov wrote:
> There is no any "<% ... %>" in the audit jsp. Below is one simple
> example of such file:
>
> <%@ include file="/common/all.include.jsp" %>
>
> <c:if test="${ audit != null }" >
> <log:info msg="${ audit.event } : ${ audit.userName }" />
>
> <security:login loginName="${ audit.userName }" event="${
> audit.event }" sessionId="${ audit.sessionId }" />
> </c:if>
Oh, I get it. You're using JSP to script Java, rather than just using
Java. Good luck with that. :(
By the way, your JSP generates plenty of output, even if it /is/ just
whitespace.
> This is actually what made me go this way. With ability to define new
> tags using JSP (taglib) it is truly possible to have "java-less" JSP
> application.
So, by writing tons of taglib code, you can effortlessly script Java. Yup.
To answer your original question: I don't believe that there's an easy
(or natural) way for you to do what you want to do. Since this is Not
Recommended Technique(TM), I'm not going to spend any more time on it.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHDB079CaO5/Lv0PARAq9nAJ0Z+9AasT23uorxQAv0SgZwUQ0K5ACfTxyQ
twgNiUTwXBeu7tLY3SYfkzM=
=I7XT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using RequestDispatcher.include() outside of Request/Response cycle.
Posted by Andrei Tchijov <an...@tchijov.com>.
There is no any "<% ... %>" in the audit jsp. Below is one simple
example of such file:
<%@ include file="/common/all.include.jsp" %>
<c:if test="${ audit != null }" >
<log:info msg="${ audit.event } : ${ audit.userName }" />
<security:login loginName="${ audit.userName }" event="$
{ audit.event }" sessionId="${ audit.sessionId }" />
</c:if>
"audit" is a hashtable object in session. it has all information
needed ( "event" - login|logout| .... , "userName", "sessionId" ).
<security:login> is a custom tag which does not have any <% ... %> in
it either just some <sql:...> tags.
This is actually what made me go this way. With ability to define new
tags using JSP (taglib) it is truly possible to have "java-less" JSP
application. Audit is the only spot which required some java coding,
with this JSPAudit valve I can code it once and then delegate all
actual audit business logic to JSP writer.
On Oct 9, 2007, at 5:54 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrei,
>
> Andrei Tchijov wrote:
>> I would love to let JSP application developers to stay in one
>> language
>> environment (JSP). And as soon as pretty much all but auditing
>> could be
>> done in JSP (especially with JSTL), I feel that it will be nice (and
>> appropriate) to let people to code audit functionality using JSP as
>> well.
>
> I don't believe this is an appropriate use of JSP technology; I
> believe
> it to be an abuse of it. Are you trying to use JSP's ability to
> produce
> textual output, or do you just have regular Java code inside <% and %>
> tags? If that's the case, then your developers aren't writing JSP:
> they're writing Java and wrapping it in JSP.
>
>> And besides that one issue, this idea works just fine.
>
> How do you get request and response objects for other events so
> that the
> JSP has access to them?
>
> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHC/h99CaO5/Lv0PARAsvWAJ9A5ME1qG7mQerIkyK9sshcgSWyvACfcUY8
> 6/0EMnwlVR6huHi/0agEBn8=
> =1qrf
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using RequestDispatcher.include() outside of Request/Response
cycle.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrei,
Andrei Tchijov wrote:
> I would love to let JSP application developers to stay in one language
> environment (JSP). And as soon as pretty much all but auditing could be
> done in JSP (especially with JSTL), I feel that it will be nice (and
> appropriate) to let people to code audit functionality using JSP as
> well.
I don't believe this is an appropriate use of JSP technology; I believe
it to be an abuse of it. Are you trying to use JSP's ability to produce
textual output, or do you just have regular Java code inside <% and %>
tags? If that's the case, then your developers aren't writing JSP:
they're writing Java and wrapping it in JSP.
> And besides that one issue, this idea works just fine.
How do you get request and response objects for other events so that the
JSP has access to them?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHC/h99CaO5/Lv0PARAsvWAJ9A5ME1qG7mQerIkyK9sshcgSWyvACfcUY8
6/0EMnwlVR6huHi/0agEBn8=
=1qrf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using RequestDispatcher.include() outside of Request/Response cycle.
Posted by Andrei Tchijov <an...@tchijov.com>.
I would love to let JSP application developers to stay in one
language environment (JSP). And as soon as pretty much all but
auditing could be done in JSP (especially with JSTL), I feel that it
will be nice (and appropriate) to let people to code audit
functionality using JSP as well. And besides that one issue, this
idea works just fine.
On Oct 9, 2007, at 4:52 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrei,
>
> Andrei Tchijov wrote:
>> I can (and do) add session listener, so it is not a problem to detect
>> that session timed out. The problem is how to invoke my audit JSP
>> page.
>
> Why not just do your audits right in the session listener? JSPs are
> not
> meant for this type of thing.
>
>> Audit JSP page does NOT produce any output and it does NOT require
>> any information from Request
>
> So why is it a JSP?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHC+oa9CaO5/Lv0PARAjOkAJ958yvgszMuxPUS+28D65swBjCXoQCfWPC7
> KO5B/+kH2xFXPIhgxgAFFSk=
> =yfpo
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using RequestDispatcher.include() outside of Request/Response
cycle.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrei,
Andrei Tchijov wrote:
> I can (and do) add session listener, so it is not a problem to detect
> that session timed out. The problem is how to invoke my audit JSP
> page.
Why not just do your audits right in the session listener? JSPs are not
meant for this type of thing.
> Audit JSP page does NOT produce any output and it does NOT require
> any information from Request
So why is it a JSP?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHC+oa9CaO5/Lv0PARAjOkAJ958yvgszMuxPUS+28D65swBjCXoQCfWPC7
KO5B/+kH2xFXPIhgxgAFFSk=
=yfpo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using RequestDispatcher.include() outside of Request/Response cycle.
Posted by Konstantin Kolinko <kn...@gmail.com>.
Hi, Andrei!
You may consider looking at existing "mock" implementations of
HttpServletRequest/Response that are available.
For example, Spring Framework (http://springframework.org) has
org.springframework.mock.web.MockHttpServletRequest,
org.springframework.mock.web.MockHttpServletResponse
Those are in spring-mock.jar if you download Spring.
Some testing frameworks also have similar objects.
I used MockHttpServletResponse to catch and ignore output from a
subrequest in my webapp, but it was in the context of request/response
processing, and the original request was available there to perform
the call.
I suppose that you cannot use a mock request in such a way, because
it has a lot of information with it. E.g. how are you going to implement
request.getRequestDispatcher()? There can be also other issues,
e.g. attributes of the request may store additional information,
that may be required to process the request. You may learn from
the code though.
These mock objects are used to test how the framework behaves outside
of a servlet container. They are not intended to fool the container.
You also cannot use some earlier request/response. When the session times out,
that event has no relation to any requests being processed by the server at
the moment.
You may also open a new connection, using URL.openConnection(), but that
is too much overhead for your task. You should consider rewriting your audit
logic.
Best regards,
Konstantin
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using RequestDispatcher.include() outside of Request/Response cycle.
Posted by Andrei Tchijov <an...@tchijov.com>.
Thnx for reply! I thought that it should be possible. Was just
looking for some pointers about which methods are important and which
are not in Request/Response.
On Oct 9, 2007, at 10:34 PM, Lilianne E. Blaze wrote:
> Hello,
> Consider using either Request / Response Wrappers subclassed and
> modified so they simply return 0 / null / "" / ignore output, or
> google
> for "servlet api mock objects" or something similar.
> Ages ago I wrote something similar, where specified pages were
> called on
> webapp start / stop. Don't ask :/
> It was on Tomcat 4.0, but I believe there's nothing in the specs that
> prohibit such (ab)use, so it should work with any servlet container.
>
> Greetings, Lilianne E. Blaze
>
> Andrei Tchijov wrote:
>> Hi,
>> I have a valve which detects some events in life-cycle of a web
>> application ( like successful login/failed login/logout ) and invokes
>> some configurable JSP page to let it perform some audit auctions (
>> like putting records in the table which trace access to application
>> ). It works fine, the only problem is auditing session timeouts. I
>> can (and do) add session listener, so it is not a problem to detect
>> that session timed out. The problem is how to invoke my audit JSP
>> page. RequestDispatcher.include() require Request and Response
>> objects
>> which are obviously not accessible inside SessionEvent callback.
>> Should I create some sort of "fake" Request/Response objects? Can I
>> reuse some Request/Response objects from earlier (like when valve
>> detected creation of the session)? Audit JSP page does NOT produce
>> any output and it does NOT require any information from Request, so
>> this Request/Response objects only need to be able to make
>> RequestDispatcher.include() happy.
>> Your thoughts will be highly appreciated,
>>
>> Andrei Tchijov
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using RequestDispatcher.include() outside of Request/Response
cycle.
Posted by "Lilianne E. Blaze" <li...@tlen.pl>.
Hello,
Consider using either Request / Response Wrappers subclassed and
modified so they simply return 0 / null / "" / ignore output, or google
for "servlet api mock objects" or something similar.
Ages ago I wrote something similar, where specified pages were called on
webapp start / stop. Don't ask :/
It was on Tomcat 4.0, but I believe there's nothing in the specs that
prohibit such (ab)use, so it should work with any servlet container.
Greetings, Lilianne E. Blaze
Andrei Tchijov wrote:
> Hi,
> I have a valve which detects some events in life-cycle of a web
> application ( like successful login/failed login/logout ) and invokes
> some configurable JSP page to let it perform some audit auctions (
> like putting records in the table which trace access to application
> ). It works fine, the only problem is auditing session timeouts. I
> can (and do) add session listener, so it is not a problem to detect
> that session timed out. The problem is how to invoke my audit JSP
> page. RequestDispatcher.include() require Request and Response objects
> which are obviously not accessible inside SessionEvent callback.
> Should I create some sort of "fake" Request/Response objects? Can I
> reuse some Request/Response objects from earlier (like when valve
> detected creation of the session)? Audit JSP page does NOT produce
> any output and it does NOT require any information from Request, so
> this Request/Response objects only need to be able to make
> RequestDispatcher.include() happy.
> Your thoughts will be highly appreciated,
>
> Andrei Tchijov
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org