I am new to J2EE and related stuff in general. I am trying to move a particular web application from a Sun One server deployment on to JBoss. The application is filled with a lot of servlets where each one re-directs to another.
There are way too many servlets for me to enter a mapping between each of these servlet class to a URL-mapping individually in web.xml. The application code has many redirects where they name the servlet class names itself in the redirect-URL. As of now when I run it on JBoss the redirections to URL with servlet classnames in URL don't seem to work on JBoss (it gives a 404: Not Found, probably since there is no mapping in the web.xml). So is there any config setting that I can set to allow this to happen or should manually enter each and every URLpattern-to-Servlet mapping in the web.xml?
Thank you.
There are two solutions.
As we know JBoss uses Tomcat under the hood as a servlet container. You can enable invoker servlet, that would save you from mapping the whole lot in web.xml. But beware, it will be naive to do that, and not at all encouraged.
Secondly, you can write another servlet/filter and map just that in your web.xml for every url pattern, may be. Then that new servlet of your can forward the requests to whatever servlet it should.
I hope you get my point.
Not sure what you mean by this
the application code has many redirects where they name the servlet class names itself in the redirect-URL
Do you have hardcoded urls in the servlet classes? How many servlets? If you have hardcoded urls they may all have broken because the context is slightly different, or the appname, etc.etc. Can you post an example?
Well, there are some hard-coded URLs in the code, but even if i typed in the right URLs in browser directly I still get a 404. There are about 30 servlets (a conservative approximation). Ex: http://FQDN_SERVER.com/?arg1=ABCD&arg2=XYZ
Here the servlet-classname is literally the classname of the servlet without ".class" extension, which may not be a good practice. But the code is full of such redirections and if I have to change this then I have to add a new url-pattern to each of these servlets in the web.xml and construct a new red-rect URL for each of these servlets. So is there anyway I can avoid this or will I have to go through the pain of doing the above mentioned?
Thanks,
Manoj
Sorry the URL-pattern looks this http://FQDN_SERVER.com/servlet-classname?arg1=ABCD&arg2=XYZ
Related
I'm trying to use Spring Web on Tomcat to build an API server. This is just a request-response API, not a full web app - it won't have any web pages or static assets like images. As such, I think SpringWebMVC is the wrong technology since I don't actually want the MVC part of it, so I'm just just trying to use plain old SpringWeb.
Unfortunately, practically every tutorial I've found online uses the org.springframework.web.servlet.DispatcherServlet which is from the MVC package, not from the base package. In the base package, the only viable HttpServlet implementation I found was org.springframework.web.context.support.HttpRequestHandlerServlet. However, this servlet doesn't seem to honor #RequestMapping or #RequestBody or #ResponseBody annotations in the handler.
I thought perhaps I'd just create multiple handler servlets and just use the url-pattern on each of them in the web.xml to route them correctly, but it turns out url-pattern doesn't support path variables either (at least as far as I can tell).
So is there a way to properly set up this servlet to be able to handle request mappings with path variables like so?:
GET /foo/{fooId}
POST /foo/{fooId}/fooOperation
POST /bar/{barId}/barOperationA
POST /bar/{barId}/barOperationB
POST /bar/{barId}/barOperationC
Set-Up-
I have a JSP - index.jsp and a servlet indexController. indexController forwards request to index.jsp. Execution of index.jsp without execution of indexController is not desired.
Requirements-
'www.mysite.com' should be served by indexController/index.jsp
Any request with invalid url should get redirected to 'www.mysite.com'.
'www.mysite.com/index.jsp' should get redirected to 'www.mysite.com'.
My Solution -
Map indexController to "/" - I read that this is overriding 'default servlet' and I want to avoid that.
Map 'index.jsp' in welcome-file-list: I don't need to explicitly map it science 'index.jsp' is there, it will be automatically taken as welcome file. Doing this doesn't execute indexController. Moreover invalid urls are 'forwarded' not redirected to welcome file.
Map error page to home page- This is cheating with yourself. I don't want to hide errors.
Use two servlets. One with "/*" mapping, which redirects everything to 'mysite.com'. Second mapped to ""(empty) that actually serves request. - Some mysterious issues here(yet to figure out)
I think, everyone wants to achieve same functionality for their home screen and there are many questions at stackoverflow with similar problems.
Is there any standard solution which solves problem for once and for all.
Edit:- There were only 7 views in more than 30 mins. Removed GAE tag, to attract more views.
Simply put a web server before your app server and you can map any URL to any application/page. Also don't publish an app server directly.
Are you using Tomcat I presume, so you probably deployed ROOT application, right? (you should go with the web server anyway)
I have a project that I can see the JSP's... However Jboss shows me the servlets so in the address bar all i can see is:
"appservleer?=AppDev"
This is an example not the actual address...but with that info only how can I know which JSP is being displayed at that moment by JBoss.
or am I understanding this Jboss, servlet, JSP incorrectly?
Some guidance would be appreciated.
Thanks.
You cannot know which jsp is being displayed unless the developer decided to give hints about it.
A jsp is just a view technology that the servlet uses to render a response. That is, typically, the jsp will be parsed and html will be generated. However, the developer of the servlet may decide to write to the response himself. So nothing can really tell you if what you got came from a jsp or from another source, even if you had a url like www.mydomain.com/page.jsp. Nothing guarantees the response you are seeing in your browser was generated from a jsp.
The only way to know for sure which JSP is used for rendering is to look at the source code of the servlet that is mapped under (in your example) "appservleer".
Look in web.xml which servlet is mapped with this path, and open the source code of this servlet. Then figure out the execution path, starting with the doGet(...) or the doPost(...) method, and see to which JSP it is forwarded in the end...
Good luck.
You should always start with the web.xml file which will eventually lead you to the actual jsp file that is displayed. Start with the servlet mapping and check which servlet is invoked for the url. Then dig into the servlet to find out which jsp it is redirected to. If you are using any application framework then look for the implementation to findout the mapping. For e.g. in spring the spring configuration files or the controller classes tells you where the calls are redirected to.
I've never come across this extension before. It's being used for a front-end interface to a j2ee backend.
It's probably just a URL pattern for firing a Struts action. Most people stick with the .do convention, but you can make the actions fire on just about anything you want.
See Section 5.4.2 on this site for more info
This is servlet mapping in j2ee application where you can define the url pattern for a particular servlet and you can name it as you want in this one it name like .action you can give like .yourname or anything.
This mapping you can give in your web.xml using servlet-mapping tag and url-patten tag in it.
Thanks
I have a very basic question about MVC web applications in Java.
Since the olden days of raw JSP up until current technologies like Seam, a very basic pattern has always been the internal dispatch from the controller that initially accepted the request to the view layer that creates the output to be sent to the client.
This internal dispatch is generally done (although the mechanism may be hidden through an extra layer of configuration) by asking the servlet container for a new resource using a URL. The mapping of these URL are done by the same web.xml that also defines the "real" URL to the outside.
Unless special measures are taken, it is often possible to directly access the view layer directly. Witness the Seam "registration" demo, where you can bypass "register.seam" and directly go to "registered.xhtml". This is a potential security problem. At the very least, it leaks view template source code.
I am aware that this is only a basic sample application, but it is also strange that any extra measures should need to be taken to declare these internal resources invisible to the outside.
What is the easiest way to restrict URL entry points?
Is there maybe something like the "WEB-INF" directory, a magic URL path component that can only be accessed by internal requests?
You can prevent access to internal resources by using a security-constraint in your web.xml deployment descriptor.
For example, I use the following configuration to prevent direct access to JSPs:
<!-- Prevent direct access to JSPs. -->
<security-constraint>
<web-resource-collection>
<web-resource-name>JSP templates</web-resource-name>
<url-pattern>*.jsp</url-pattern>
</web-resource-collection>
<auth-constraint/> <!-- i.e. nobody -->
</security-constraint>
I would not recommend allowing Internet requests to directly access your appserver. I'd throw a webserver in front, then in it, allow the request of certain kinds of URLs. Don't want people to go to foo.com/jsps? Restrict it once and for all there.
There's a bit of a conversation on the topic here: hiding pages behind WEB-INF?
One way to handle this would be to construct a Servlet Filter which examines the request path of every request and handles each request accordingly. Here is a link that could help get you started, JavaServer Pages (JSP) and JSTL - Access control with JSP
I have now seen a couple of applications that put their internal JSP into WEB-INF/jsp. That seems to do the trick, at least for JSP, and also for Velocity. It does not seem to work for JSF, though.