Harpartap Singh

Greenhorn
+ Follow
since Sep 14, 2002
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Harpartap Singh

Having worked with servlets,jsp,jdbc I am ready to go in through the J2ee technologies


"Having worked with servlets,jsp,jdbc..." It appears you have already covered most of the J2EE.
Ed Roman's "Mastering Enterprise JavaBeans" is an excellent tutorial for EJBs.
Shawn, thanks a lot for answering my verbose questionaire. (it was actually a code review in disguise )
I guess I should get the "JSTL in Action" and start reading it.
thanks,
/hs
21 years ago
JSP
But, I thought another advantage of using <c:import> was that you are not bound to "relative URL" anymore.
So if there was a [B]<c:forward>[B] we could forward requests to another web application's URL without having to go through the circus of getContext, getRequestDispatcher, forward etc.
Isn't convenience a motivation for JSTL?
21 years ago
JSP
I have a question for Shawn Bayern....
The JSTL core library has the following tags:
<c:import>, <c:redirect>.
How come there is NO <c:forward>? I am assuming that <c:import> is a dynamic include functionality, so why not a dynamic <c:forward>?
thanks,
/hs
21 years ago
JSP
I need a sanity check. I am implementing templates using custom tags. The custom tag calls pageContext.include() which in turn intantiates the same custom tag.Here is the scenario, question, and code
I realize the fact that "if a custom tag occurs multiple times on a JSP page, a single instance of the tag handler may be used to handle all of those occurences"
In this case, fileA.jsp instantiates the RenderTag (template:render). The nested tag PutTag (template ut) gets the section/content pairs of values and stores the values in the REQUEST_SCOPE of the pageContext useing pageContext.setAttribute(section,content,PageContext.REQUEST_SCOPE) . The PutTag doesn't play any more part.
Next the doEndTag() of RenderTag instance dynamically includes the file "templateFile.jsp".
This is where I have questions:
1. In the included file the RenderTag is instantiated again. It instantiates a NEW RenderTag object. CORRECT?
2. But since this included file is a NEW jsp file, it has its own NEW pageContext , but calling pageContext.getAttribute(section,REQUEST_SCOPE), should retrieve the ORIGINAL section/content pair that I had stored in the outside files pageContext. I believe this is the case, because the included file did get the SAME request object, and the stored section/content pair of values came with it. CORRECT?
I have tested this and it works. I want to confirm that my understanding of same tag instantiation in included files is correct. And I also want to confirm my understanding that sharing attributes using REQUEST_SCOPE of different pageContexts is a safe way, as long as we are dealing with "included" files in the same request.
realFile.jsp

templateFile.jsp

RenderTag.java

Thank you so much for reading this far.
/hs
21 years ago
JSP
Try this -

This should do the trick.
/hs
21 years ago
JSP
Anyone taken a look at the following book by James Turner? Its been out since march 2002.
"MySQL and JSP Web Applications: Data-Driven Programming Using Tomcat and MySQL"
Could you please share your "reviews". Good, bad, other books (bible) covering this topic...
Amazon link to this site
21 years ago
JSP
Whoa, didn't notice that Paul Wetzel asked this question in Dec 2000. By now he is probably writing his own Application Server.
21 years ago
Paul,
I develop on JRun 4.0 and our deployment is on Tomcat and our application has no problems going back and forth. Hence the decision for you should not be that hard, even if you start off with Tomcat and decide to migrate to JRun for EJBs down the road, the transition should not be a big deal.
/hs
21 years ago
One way to find out about "session timeout" is by doing a search in javaranch forums.
Well here is a sample session timeout discussion for you.
And about creating/destroying sessions - request.getSession(true) will create one for you and HttpSession.invalidate() will destroy it for you.
/hs
21 years ago
Sorry I didn't read your question carefully. You need to detect session invalidation for "redirect"ing to login page.
Well, in that case you dont' need listeners to detect invalidation.
In the servlets that you are controlling access to, each time they are accessed (in doXXX() methods), check to see if a session exists, if not, redirect them to login servlet

Just remember a gotcha regarding sessions and JSP pages (not servlets):
- if you don't have the directive <%@ page session="false" %> in your jsp page, if a session does not exist, a NEW one will be created for you automatically.
21 years ago
And, about detecting session invalidation, you have to use the Event listener. In this case the HttpSessionListener. Write a class that implements the <b>HttpSessionListener interface</b> and override the <b>sessionDestroyed()</b> method.
Inside the sessionDestroyed() remember to call <b>HttpSessionEvent.getSession()</b> to really tell, which session was destroyed.
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/servletapi/javax/servlet/http/HttpSessionListener.html
About setMaxInactiveInterval(1) or (60) behaving the same, make sure you are setting the inactive interval on the correct session. It could be using the system default, or the <session-config> <session-timeout> elements in the web.xml.
If you still can reproduce this, please post the application server/version you are using, so someone else could reproduce it.
/hs
21 years ago
I bet $1 that you will be scolded within the next 12 hours by the "Name Police".
"your name no good"
21 years ago
Get the ServletContext of the OTHER web app.
Using this new ServletContext, create a RequestDispatcher to the servlet you want to access, and then forward your request...

Or something like this.
/hs
21 years ago
The doGet() method of Servlet interface can only throw the following three exceptions or their subclasses:
ServletException
IOException
RuntimeException
For custom, self-defined exceptions, wrap them in ServletException and rethrow the ServletException.
e.g:
catch( DataStoreException ex ) {
throw new ServletException( "Wrapped Excep", ex );
}
In the web.xml:

<error-page>
<exception-type>DataStoreException</exception-type>
<location>myErrorHandlingPage.jsp</location>
</error-page>
In your myErrorHandlingPage.jsp:

use the ServletException.getRootCause() to read the wrapped exception
NOTE: Even though you are throwing ServletException from doGet(), the conainer will call the ServletException.getRootCause() to find the wrapped exception and match it your <error-page> definition. BUT, remember not to have a generic <exception-type>ServletException</exception-type> in your web.xml, because then the container will just hand over your exception to this generic's corresponding location.
Hope this helps.
/hs.
21 years ago
JSP