I have a project due (actually overdo) for school and cannot get something simple working.
I am running Netbeans 7.2.1, Glassfish 3.1.2.2 and the latest Java JDK.
I have four JSF pages, index.xhtml ItemAdd.xhtml, ItemCatalog.xhtml, and ItemDetail.xhtml and a servlet SessionServlet. I have verified that I can directly reach each of the pages i.e
http://localhost:8080/CMIS440Spitzer-Project2/faces/ItemDetail.xhtml
works. However when I go from one of the JSF pages to my servlet and then forward the request on I get a glassfish 404 error.
Here is my extremely simple servlet code that is doing the forwarding:
if (request.getParameter("target").contains("Add Item")) {
String URL = request.getContextPath() + "/faces/ItemAdd.xhtml";
System.out.print(URL);
RequestDispatcher dispatcher = request.getRequestDispatcher(URL);
dispatcher.forward(request, response);
}
One the console I get the following which I can paste into my browser and it works:
INFO: /CMIS440Spitzer-Project2/faces/ItemAdd.xhtml
Since I get the console message I know the request is reaching the servlet and that it is hitting the right code block and because I get a Glassfish 404 error I know it is forwarding to my machine on the correct port.
What is the issue with the RequestDispatcher? Why is this not working?
Thanks.
<rant>
This encompases more then this issue but I have worked with PHP, perl, C++, C, Java and a few others. NEVER before have I felt that a language (in this case the JSF implementation of Java) was actively trying to make my life as difficult as possible. For example, many needed things in this environment is in the form of maps:
Need a list of all request parameters, you get a map, need a list of all session parameters, you get a map, etc. However in JSF you cannot easily LOOP THROUGH MAPS! Why, because it is slow. I found a link that was basically a Mea Culpa from a Java developer who mentioned it would be O(N) speed so it would be slow. In other word the Java JSF developers pre-optimized my code and require me to convert maps to lists.
At one point in this I was getting some weird error regarding reflection and accessing private methods/properties when now-where in my code was I doing anything of the kind. I was using standard getters/setters to return a map keyset.
Dont even get me started on the naming conventions of getters/setters (uppercase converted to lowercase, add a get/set in front)
Maybe its me but this whole setup seems overly obtuse,hard to understand and unnecessarily complicated.
Thanks for reading my rant. I have been at this WAY longer then I thought I should and have been nearly to tears trying to do simple stuff.
</rant>
Why are you mixing servlets for session management and JSF pages? when working with JSF, you have to stop thinking in terms of the http request/response paradigm, it's an event-driven framework with more in common to desktop GUI programming. Granted, JSF is not the friendliest web framework to work with, but you're making it more complicated than it needs to be.
The path you pass to getRequestDispatcher is relative to the context root.
By adding the context path to it, you're ending up with /CMIS440Spitzer-Project2/CMIS440Spitzer-Project2/faces/ItemAdd.xhtml, which doesn't exist.
(Actually, it's relative to the context root if it starts with a slash, as this one does. If it doesn't start with a slash it's relative to the servlet.)
Related
Have three Grails applications deployed on the same Tomcat server (tomcat-7.0.54) and after a few (3-4) days, we seem to get stuck in a redirect loop in either one or two of the applications after logging in. One application always seems to be fine, and never have issues. All three have the same CAS config, copied from one application to the other, with the only differences being the intercept URL maps.
Anyone experienced this, or have any idea where to look? We end up having to restart tomcat in order for the problems to go away, and once we do, all three will be fine for another 3-4 days.
Hi Few days back i also faced this problem, in my situation i just called the url of app1 form my parent application for single sign-on. after successful log-in the app1 is looping. the mistake i did is i just passed the url like "domainname:8080/app1" it will always look for home/index/login page so this looping is happens. i just changed the url like "domainname:8080/app1/login.action", check this it may be useful to you.
I'm pretty experienced in HTML, CSS, javascript, SQL, IIS, and a little Apache, but have essentially no knowledge of Java or Tomcat. I have a client with a low budget and a legacy web site based on a proprietary CMS (an ancient version of this) built on jakarta tomcat. Upgrading is not an option and paying tms to develop is also not an option. I'm much cheaper.
The URLs of the pages and documents on the site tend to be pretty long and not very meaningful to humans. For one reason or another when they are doing promotions they want shorter URLs for particular content. For example they may want http://{server}/naftir.html to redirect to http://{server}/cmspreview/content.jsp?id=com.tms.cms.section.Section_1013_sub_options.
I've solved this by a kludge of putting (for example) a naftir.html file in the root directory of the server and writing the redirects in there. But the {whatever}.html files are piling up and it seems there should be a better solution. E.g. edit the 404 file to look in a list (or MySQL table) of short names and desired redirects to do the redirection if found, otherwise display the 404. Or some other method based on a list of short names and redirect URLs rather than loads of files.
Any ideas?
You can easily configure a lot of this kind of stuff using a tool called urlrewrite. It's a Filter that you configure in WEB-INF/web.xml to run for all the URLs you want to re-map. Then, there is a "rewrite" configuration file where you can map specific incoming URLs to outgoing URLs. You can even use parametric replacements like mapping /foo/* to /a/b/c/d/*.
You can simplify the configuration by mapping the urlrewrite filter to all URLs, but then you lose a bit of performance on all the URLs that aren't ultimately rewritten.
I have to call a servlet written in Java from Clojure web application, and I don't understand how to do that.
Developing a webapp in Java, I had to describe all mappings in web.xml. In Compojure, I see, I must describe routes. So, can I bind the Java servlet to one such route?
Sorry if my question is stupid, but I've searched a lot and didn't find an answer; I'm just starting to develop for the web.
Two helpful pointers:
There's an example on how to generate the Vaadin servlet completely from Clojure on github
And here's a SO question on how to map a java filter to routes
I suggest, there is only one way to cope with my tasks. I have to manually instantiate Java servlets in Clojure web app and form their request and response parameters. Test package for ring.util.servlet library describes this approach in details, but in case of turning Ring handler into a Java servlet.
In case of deploying Clojure app and Java servlets to servlet container separately there's no need to define additional Compojure routes or Ring handlers to paths mapped by container.
Please tell me whether my suggestions are incorrect.
I'm playing with a GWT/GAE project which will have three different "pages", although it is not really pages in a GWT sense. The top views (one for each page) will have completely different layouts, but some of the widgets will be shared.
One of the pages is the main page which is loaded by the default url (http://www.site.com), but the other two needs additional URL information to differentiate the page type. They also need a name parameter, (like http://www.site.com/project/project-name. There are at least two solutions to this that I'm aware of.
Use GWT history mechanism and let page type and parameters (such as project name) be part of the history token.
Use servlets with url-mapping patterns (like /project/*)
The first choice might seem obvious at first, but it has several drawbacks. First, a user should be able to easily remember and type URL directly to a project. It is hard to produce a human friendly URL with history tokens. Second, I'm using gwt-presenter and this approach would mean that we need to support subplaces in one token, which I'd rather avoid. Third, a user will typically stay at one page, so it makes more sense that the page information is part of the "static" URL.
Using servlets solves all these problems, but also creates other ones.
So my first questions is, what is the best solution here?
If I would go for the servlet solution, new questions pop up.
It might make sense to split the GWT app into three separate modules, each with an entry point. Each servlet that is mapped to a certain page would then simply forward the request to the GWT module that handles that page. Since a user typically stays at one page, the browser only needs to load the js for that page. Based on what I've read, this solution is not really recommended.
I could also stick with one module, but then GWT needs to find out which page it should display. It could either query the server or parse the URL itself.
If I stick with one GWT module, I need to keep the page information stored on server side. Naturally I thought about sessions, but I'm not sure if its a good idea to mix page information with user data. A session usually lives between user login and logout, but in this case it would need different behavior. Would it be bad practise to handle this via sessions?
The one GWT module + servlet solution also leads to another problem. If a user goes from a project page to the main page, how will GWT know that this has happened? The app will not be reloaded, so it will be treated as a simple state change. It seems rather ineffecient to have to check page info for every state change.
Anyone care to guide me out of the foggy darkness that surrounds me? :-)
I'd go with History tokens. It's the standard way of handling such situations. I don't understand though, what you mean by "It is hard to produce a human friendly URL with history tokens" - they seem pretty human friendly to me :) And if you use servlets for handling urls, I think that would cause the whole page to be reloaded - something which I think you'd rather want to avoid.
Second, I'm using gwt-presenter and
this approach would mean that we need
to support subplaces in one token,
which I'd rather avoid.
If you are not satisfied with gwt-presenter (like I was :)), roll out your own classes to help with MVP - it's really easy (you can start from scratch or modify the gwt-presenter classes) and you'll get a solution suited to your needs. I did precisely that, because gwt-presenter seemed to "complicated"/complex to me - to generic, when all I needed was a subset of what it offered (or try to offer).
As for the multiple modules idea - it's a good one, but I'd recommend using Code Splitting - this type of situation (pages/apps that can be divided into "standalone" modules/blocks) is just what it's meant to be used for, plus you bootstrap your application only once, so no extra code downloaded when switching between pages. Plus, it should be easier to share state that way (via event bus, for example).
Based on what you have posted I presume you come from building websites using a server side framework: JSP, JSF, Wicket, PHP or similar. GWT is not the solution for building page-based navigational websites, like you would with the aforementioned frameworks. With GWT, you load a webapp in the browser and stay there. Handle user events, talk with the server and update widgets; using gwt-presenter is a good thing here as you are forced to think about separation of controller logic and view state.
You can really exploit all features of GWT to build a high-performance app-in-the-browser, but it is definately not meant for building websites (using hyperlinked pages that transfer request parameters via the server session).
This is by far the most widely asked question about GWT here # StackOverflow :)
"How do I define pages and navigation between them in GWT?" Short answer: "You don't."
Use Wicket instead, it runs on the App Engine just fine and enables you to define page bookmarks and all stuff you mentioned above. Look here: http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.html
I need to execute a JSP. But I need to directly from Java, without using Tomcat or any other servlet container. Compiling JSPs would be a good thing too, but not necessary. I think maybe org.apache.jasper package is good for doing this, but I can't find any good example or tutorial online.
I need something as:
Class compiledJSP = compileJSP(new File("helloWorld.jsp"));
String html = executeJSP(compiledJSP, httpServletRequest, httpServletResponse, ...);
html --> "Hello World, John!"
Thanks!
If you need to capture JSP's output as string it's reasonably straightforward (although far from ideal from the design point of view) from within Servlet Container:
1. Extend javax.servlet.HttpServletResponseWrapper and override getWriter() / getOutputStream() methods to provide your own buffered versions (e.g. StringWriter)
2. Invoke "include()" method of RequestDisparcher, wrapping original response in your own.
3. Grab buffer's content.
Now if you need to do the same thing outside Servlet Container, you really need to ask yourself "why?". Perhaps you should be using a template engine (FreeMarker / Velocity / StringTemplate / etc...) instead of JSPs? If your JSPs are well-formed XML files and are not using any java code inserts it may be reasonably trivial to convert them to FreeMarker templates (FreeMarker supports custom JSP tag libraries) which would greatly simplify your task.
Nevertheless, if it's an absolute hard requirement your most straightforward options are:
1. Run an external Servlet Container and let it handle JSP interpretation. Your program would submit HTTP requests to it and capture the output.
2. Same as above, but you can run embedded Servlet Container (e.g. Jetty).
If your JSPs are available at build-time you can precompile them via Jasper as suggested in other answers.
I would strongly advice against trying to implement your own servlet container - you'll be walking into a world of hurt.
You will need a container. A JSP is an abstraction on Servlet. Servlets have a dependency on a life cycle provided by a container.You need a container to provide the life cycle.
This is possible without a servlet container. There are two steps to it.
The first is to generate the source code. If you look at the source code of the jspc ant task it is possible to do it directly in code. Or you could just invoke the ant task.
The code that is generated is just a Servlet and it is possible to invoke the methods on a servlet outside of a container:
Just instantiate it and then call doGet(request, response). I'm not sure exactly what you need this for but your life will be made easier using spring mock objects for the http request and response.
This will populate the Response object. you can then get the output with:
res.getContentAsString();
See an example here:
http://ytreyvus.blogspot.com/2007/03/private-void-cloneplaneffectrelationshi.html
Try MockRunner to execute it. You'll need to compile the JSP first, though. I'm using Maven 2 for this (and the JSP Compiler plugin)