On Tue, 2012-06-19 at 08:48 +0530, Kiran Badi wrote: > No its not returning source code.I have couple of jsps where in I use EL > in those to access session objects and directly accessing those jsps is > not something I want.
Good move. <SNIP> > >> 2. Is their any extra setting that is required if I move my JSP's inside > >> web-inf.I created a folder under web-inf and create sample hello > >> world.jsp and then tried to invoke that jsp but got 404 message. > >> > > First of all, it's WEB-INF. Case matters. > Ok got it. > > > > > > No, there's no special "setting" that will directly expose anything > > under WEB-INF via a URL. That's the part of the Servlet Spec. It's a > > Good Thing®. However, if you're trying to make your JSPs inaccessible > > via URLs, then you can move them there and have them indirectly accessed > > using a servlet which forwards the request to them. See > > ServletContext.getRequestDispatcher() and RequestDispatcher.forward(). > Yup I have lot many of request dispatchers in servlets.Almost all my > JSP's are using data which is forwarded by servlets.I pull data from db > via servlet, store it in session scope,forward it to jsp and in jsp > access it via el.On logoff I remove attributes from the session. > > So then those JSPs which are forwarded to by servlets (typical "controllers" in MVC) could be moved to WEB-INF/whatever and then the servlets would use a dispatcher to forward to "/WEB-INF/whatever/sample.jsp" instead of "/webpages/sample.jsp" or whatever they're using now. You'd need to physically move those JSPs then update the servlets to use the JSPs' new location. > > > > Hopefully, you're trying to use or move toward the MVC (Model, View, > > Controller) pattern. If not, you should. Google "MVC design pattern". > > There are many, many frameworks that will make this easier for you (once > > you learn them): Struts, Spring MVC... > > > > If you're well into your project and don't want to add a framework to it > > you could write a simple servlet that uses an algorithm to map URI paths > > to JSPs then forwards to the JSP using a dispatcher. For instance, you > > could put your JSPs in myapp/WEB-INF/jsps. Then have the servlet map a > > URI such as /sample to /WEB-INF/jsps/sample.jsp (all relative > > to /myapp). > http://localhost:8080/mysite/WEB-INF/jsp/newjsp.jsp > > I just created folder jsp under WEB-INF and then added newjsp.jsp(this > is hello world jsp) and then ran the file.I get 404 error. I am trying > all this with netbeans. Well I hope by now you understand why or we're just going in circles. Of course, that URL gives a 404: it's trying to access WEB-INF which is never accessible via HTTP. But it is accessible via RequestDispatcher.forward() -- e.g.: servletCtx.getRequestDispatcher("/WEB-INF/jsp/newjsp.jsp").forward(request, response); This is kind of like what you said earlier that your servlets are essentially doing, right? > > This isn't a great approach because you really aren't separating the > > model from the view (all the app logic and display logic are housed in > > the JSP -- a maintenance nightmare). But if you don't have time to > > re-architect the app now, it will hide the .jsp's from "direct access". > > And it will put you in a slightly better position if/WHEN you do > > re-architect it. > I think I am using kind of MVC pattern of course the one used around 6 > to 8 years back.I am using jsp as view, servlet as kind controller and > then some beans/jstl and el to make my life easy somewhat. I would love > to work with frameworks like spring or struts someday. > They're free you know. :-) But of course, free software doesn't add hours to the day. You're basically rolling your own MVC and that will probably help you understand better what these frameworks do. But move away from this as soon as you can. They've solved a lot of problems you probably haven't even considered and they can make your applications much less brittle if you take the time to learn them well. > Ok let me explain as what I need again, > > I have form A with say about 10 fields, lets call this as jsp A. So in > browser bar it looks like http://localhost:8080/mysite/A.jsp > Ah, so you do want SOME of your JSPs to be URL accessible! Well, if A.jsp doesn't and never ever will have any dependencies on the application's state then fine. Maybe it's true today but I doubt it will stay that way. So it's probably better to be consistent and hide this as well. > User fills this A.jsp and then clicks Submit button. It posts the form > to Servlet B which does insert in the database and then forwards the > request via request dispatcher to C.jsp which has some confirmation > details in it.(Unique reference ids pulled out from DB). > So on submit, an HTTP POST is sent to http://localhost:8080/mysite/B. Then servlet B does its work and essentially invokes: ctx.getRequestDispatcher("/C.jsp").forward(request, response); then C.jsp sends back the response using data from the session. Is this right? (btw, you know your app'ss requirements better than I, but storing all data in the session isn't the only scope available. It's likely that a lot of response data needn't survive past the current request. In that case, setting request attributes would be better -- less memory needed, less likely to pick up data that's inappropriate for the current request). > Now with my existing setup if I directly give url like > > http://localhost:8080/mysite/C.jsp I go directly to C Jsp which I > should not because its not suppose to be accessed directly. > Right. Put C.jsp in WEB-INF, get a request dispatcher for "/WEB-INF/C.jsp", forward to that and go home. --tim > I want to block this behaviour and its this behaviour I call direct > access to JSP. > > I dont get source code of any of my JSP's.my setup is pretty simple with > just j2ee stuff and tomcat. > >> - Kiran > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: This is a digitally signed message part
