[iPlanet-JATO] Re: session timeout when not submitting to a handler
Mark--
I know what's happening here, but am curious about your approach. You said
in an earlier email that you were generating links directly to JSPs, but
from what you are describing, you are generating JATO-style links to access
JATO pages. Nothing wrong with that, but there is a signficant difference.
Actually, it just occurred to me, I'm wondering what your URLs look like.
The way the request dispatching works in JATO is it ignores anything after
an initial "." in the final part of the URL path. For example, a request
for "/myapp/module1/MyPage.jsp" doesn't actually try to hit the JSP, instead
it tries to hit the JATO page "/myapp/module1/MyPage".
The end result is that you may think you are accessing a JSP directly, but
are instead accessing a JATO page. The reason the request dispatching works
this way is because it is illegal to access JATO JSPs directly, and there is
actually a (disabled) JATO feature that piggybacks on the use of the
dot-delimited URL.
So, now I need to understand your intent. I wasn't really sure why you were
generating direct JSP/page links to begin with. This works against the Type
II architecture JATO uses, in which all JATO requests go back to the
controller servlet.
If you are trying to design something like a menu page, you may have thought
that it was burdensome to create a number of HREF children, plus implement
event handlers for each of them. This definitely would be burdensome beyond
just a handful of links, but this is why JATO provides other mechanisms for
doing what I'll call here "polymorphic HREFs".
Assuming this menu page scenario, the easiest thing to do is to simply use
one HREF child on the page, and add a value to it each time it is rendered
that distinguishes it from the other instances on the page. In your event
handler for the HREF, you simply check this value and use it to decide which
page to forward to. You can add a value to an HREF or Button by using the
"addExtraValue()" method. Or, if you are using JATO 1.2, you can add extra
query string NVPs right in the JSP document using the "queryParams"
attribute of the <jato:href> tag. Thus, your one HREFchild and event
handler become "polymorphic" because what they do depends on the context in
which they are invoked.
Now, I still don't have confirmation that this is what you were trying to
do, so until I do, let me explain the exception you're seeing. JATO assumes
that when a request comes in for a page that includes the pageAttributes
NVP, it is a request coming from a previously generated JATO page. Because
of the way JATO works, this means that the request dispatching code should
send the request back to the originally rendered page. For example, if Page
A renders an HREF, which the user then activates, JATO sends the request
back to Page A for handling. All of the HREFs and forms generated during
rendering of Page A actually refer back to Page A, regardless of where those
links or buttons actually pass the request in their event handlers/Command
objects.
So, what's happening when you include the pageAttributes in your HREFs is
that JATO is assuming that a request is being sent to the target page, with
the assumption that the target page has a mechanism in place to handle the
request. This assumption relies on the specification of the "originator" of
the request being specified in the request. For links/HREFs, the name and
value of the HREF is sent along with the request. For forms, the name and
value of the button that was pressed are sent in the request. JATO uses the
presence of these name/value pairs to decide which event handler, or which
Command object, to invoke to handle the request.
The exception you are receiving is saying that there was no object on the
target page that indicated it could handle the request. This is to be
expected, since you have not specified a query parameter that indicates
which CommandField child is responsible the request. However, this is where
I see the disconnect, because that is not what I believe you were trying to
do (as explained above).
So now, given all the information above, can you tell me what you're trying
to accomplish, and whether or not the info I've given you has helped you to
design a mechanism more in line with a JATO approach? If not, given that I
understand what you're trying to do, I can offer a more concrete solution.
Todd
-- Original Message --
From: <<a href="/group/SunONE-JATO/post?protectID=174166091163159191130171186101229144026 098131198043123114199021239115076086020224">Mark_Dubinsky@p...</a>>
Sent: Monday, November 05, 2001 2:54 PM
Subject: [iPlanet-JATO] Re: session timeout when not submitting to a handler
> This is the exception we get:
>
> (And BTW, leaving a blank value for the pageAttributes doesn't help)
>
>
> [05/Nov/2001 17:49:18:4] error: <portalServlet.processRequest>
> javax.servlet.ServletException: The request was not be handled by the
> specified handler
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Compiled Code)
> at java.lang.Throwable.<init>(Compiled Code)
> at java.lang.Exception.<init>(Compiled Code)
> at
> javax.servlet.ServletException.<init>(ServletException.java:107)
> at
> com.putnaminvestments.common.jato.ApplicationServletBase.dispatchRequ
> est(Compiled Code)
> at
> com.putnaminvestments.common.jato.ApplicationServletBase.processReque
> st(Compiled Code)
> at
> com.putnaminvestments.bp.portal.portalServlet.processRequest(Compiled
> Code)
> at
> com.putnaminvestments.common.jato.ApplicationServletBase.doPost(Compi
> led Code)
> at
> com.putnaminvestments.common.jato.ApplicationServletBase.doGet(Compil
> ed Code)
> at javax.servlet.http.HttpServlet.service(Compiled Code)
> at com.putnaminvestments.bp.bpServletBase.service(Compiled
> Code)
> at javax.servlet.http.HttpServlet.service(Compiled Code)
> at
> com.netscape.server.servlet.servletrunner.ServletInfo.service(Compile
> d Code)
> at
> com.netscape.server.servlet.servletrunner.ServletRunner.execute(Compi
> led Code)
> at com.kivasoft.applogic.AppLogic.execute(Compiled Code)
> at com.kivasoft.applogic.AppLogic.execute(Compiled Code)
> at com.kivasoft.thread.ThreadBasic.run(Native Method)
> at com.kivasoft.thread.ThreadBasic.run(Native Method)
> at com.kivasoft.thread.ThreadBasic.run(Native Method)
> at com.kivasoft.thread.ThreadBasic.run(Native Method)
> at com.kivasoft.thread.ThreadBasic.run(Compiled Code)
> at java.lang.Thread.run(Compiled Code)
>
>
>
> In <a href="/group/SunONE-JATO/post?protectID=210083235237078198050118178206047166136 158139046209">iPlanet-JATO@y...</a>, "Todd Fast" <<a href="/group/SunONE-JATO/post?protectID=101233080150035167169232031248066208071 048">Todd.Fast@S...</a>> wrote:
> > Mark--
> >
> > > Initially we tried to add the pageAttributes NVP as well, but that
> was
> > > causing an exception, so we stopped doing that.
> >
> > That's odd--what was the exception?
> >
> > > Our problem now is that when the SessionTimes out it does not go
> to
> > > onSessionTimeout method as in processRequestMethod of the
> > > ApplicationServletBase it looks for pageAttributes. If it is not
> null
> > > then only onSessionTimeOut method is called.
> >
> > This is sadly the only technique for determining if a session has
> timed out
> > and a new one been created, versus the initial creation of the
> session.
> >
> > > Is there any work around for this? Maybe you can suggest how to
> pass
> > > the pageAttributes without causing the initial exception?
> >
> > Definitely--let me know what the exception was and I'll be able to
> suggest
> > something. However, it shouldn't really be any harder than
> appending a
> > "jato.pageAttributes=" empty NVP on the HREF.
> >
> > Todd
> >
> > --
> > Todd Fast
> > Senior Engineer
> > Sun/Netscape Alliance
> > <a href="/group/SunONE-JATO/post?protectID=189233080150035131169232031248229208071 048">todd.fast@s...</a>
>
>
> For more information about JATO, please visit:
> <a href="http://developer.iplanet.com/tech/appserver/framework/index.jsp">http: //developer.iplanet.com/tech/appserver/framework/index.jsp</a>
>
>
>
>
>
>
>
