Application is moved by Tomcat5.0.
There will be an error if servlets-default.jar is contained in the application:
HTTP Status 404 - Servlet default is not available
However, when deleting servlets-default.jar out of application, it moved normally.
What does servlets-default.jar do?
Thank you nowaq!
Thank you Piotr Nowicki!
I'm user874235.
need more info, where did you get servlets-default.jar from?
⇒Sorry.This Application is very old.
It is not understood where servlets-default.jar was obtained.
However, I think that it probably obtained out of Tomcat.
(Incidentally servlets-default.jar’s size is 19K.)
he jar contains just a couple of files. The most important one is DefaultServlet.class.
⇒It seems that it is used in application, extending DefaultServlet.class when it checks.
The jar contains just a couple of files. The most important one is DefaultServlet.class. DefaultServlet is the default resource-serving servlet for most web applications, used to serve static resources such as HTML pages and images.
Take a look at the source files and they will tell you all.
Related
I am trying to host a React site from a Play Framework server. The React front-end is developed in a separate project and its build artifacts (static html/js/css/etc. files) are copied into my Play project's public folder.
Now I tried navigating to e.g. /page1 (where that's a React route), but I get a 404 because of course the server does not have such a route.
What I want is to replicate nginx's try_files $uri /index.html kind of functionality - if the path that's being asked for can be served (i.e. it corresponds to an asset the server knows about), it is served. Else, serve the contents of index.html without rewriting the url, so that React's routing can work.
I've tried getting this to work with just the routes file and also as a controller (with an if/else). I haven't been able to exactly replicate what in nginx is a one-liner. How could I do this?
As #vdebergue says, you can get a simplified version of what you want by adding a catch-all at the bottom of your conf/routes file.
However if you have other files in public that you'd like to still be served up correctly (for example, image files), you need to use something a little more powerful.
I wrote about this in my blog in July, but as per Stack Overflow convention, I'll expand upon it here as well. Basically, you can copy this Gist, which declares a FrontEndServingController.
The key functionality that this controller gives above the built-in Assets controller is that on first use, it recursively scans your public directory to find real files, so it knows when to serve them up, and when to serve up index.html (your React app).
Then you use it in your routes file like this:
GET / controllers.FrontEndServingController.index
GET /*file controllers.FrontEndServingController.frontEndPath(file)
You can do it simply in the route file. At the bottom of the file, add this catch all rule:
# your other routes above
# ...
GET /$any<.*> controllers.Assets.at(path="/public", file="index.html")
I got a situation that I must serve files from different folders then the one of the context my web app is running. As an example, suppose my web app is running in a servlet context on "/opt/tomcat/webapps/ROOT/" and I must serve files existent in "/opt/my_other_folder/". These folders can be changed in runtime by the client, so I can't simply add a new context pointing to these directories. I would like a solution that I wouldn't have to rewrite a web server only for that. Also, the product I work on is generic, so I can't have a solution specific to some servlet container.
Thanks!
If you're only serving files, I would consider fronting your servlet container with something like Apache HTTP Server, where you could simply use its various directives to provide a "virtual directory" pointing to an easily configured location.
Otherwise, you could write and configure a standard Java servlet that would do essentially the same thing - storing the actual path in a Java properties file that would be read by the servlet. But while this isn't a lot of work, it would be significantly more work that the above Apache HTTP Server solution. This would be very similar to several of the answers posted at Servlet for serving static content . Specifically, you could either use or extend upon Apache Tomcat's DefaultServlet. (There are some Tomcat-specific classes used in here, but they could be easily replaced with generic equivalents.) http://balusc.blogspot.com/2009/02/fileservlet-supporting-resume-and.html looks even closer to what you'd be looking for, and it is completely generic - while still having some additional, significant features.
Either of these options would be very generic, and not specific to any particular servlet container.
I'm trying to deploy my war file on JBoss 4.2.3. This application was working fine and still is working fine (sans the bugfix that I've put into my code). I have made a new war file with a bug fix in it (which involves passing some extra http request params while requesting another app's servlet). However, when I tried to deploy this seemingly innocuous war file, I see the console logs from Jboss that say the new war file has been deployed etc. However, I don't see my changes reflecting in the browser (i.e, the extra params are not being sent in the request). I've verified that the war file that has gone into /server/default/deploy is exactly the same (cksum's are the same). I tried these few usual tricks to no avail: deleted the old war file from server before deploying the new one, restarted the server to free any cached stuff. Even put a return in my servlet at entry point. But still no difference! The servlet works just like before without the fix. Any suggestions?
I request you to kindly help me. I kinda screwed if this doesn't work.
A couple of thoughts
maybe your browser is 'offline' or using the cache, try clearing the cache / refresh
delete the contents under the server/default/tmp and server/default/work folders also
You could try adding some logging statements to your application, and see if they're output when you redeploy the war...
If it is definitely being redeployed then perhaps, as skaffman says, the fix didn't work.
I'm working on a webapp that uses struts 2, spring, URL Rewrite Filter and a couple of other dependencies that I'm not sure are relevant to this. One of the url's we construct is constructed as follows:
<s:url id="blah" includeParams="get">
This works fine when deploying in jboss as a normal webapp dropped in deploy/. So then all urls are of the form http://localhost:8080/mywebapp/... and when using this tag all the get parameters get included as expected.
However we wish to deploy this code in the root context (so everything ends up under http://localhost:8080/...), so we deployed it as ROOT.war. Suddenly, all the get parameters no longer show up in the URL. I've been looking for a while and can't seem to figure out what might cause this. First I thought it was to do with the URL rewriting but it seems to be working fine. Any tips, pointers, further questions for clarification are welcome. To add to the confusion, this all also works fine when deployed in jetty (where root context is the default).
edit: I've also tried removing ROOT.war and using jboss-web.xml to deploy to root context, this exhibits the exact same problem though.
I tracked this partly down to the url rewriting being misconfigured, the get parameters weren't being added to the urls to be rewritten because 'include-query-string' wasn't set to true on urlrewrite. this meant that 'blah?querystring' wasn't being redirected to 'blah.action?querystring'. It still doesn't seem to work right now because of interrelated problems, but I will separate those out to another question.
I'm working on a project in Java using the spring framework, hibernate and tomcat.
Background:
I have a form page which takes data, validates, processes it and ultimately persists the data using hibernate. In processing the data I do some special command (model)
manipulation prior to persisting using hibernate.
Problem:
For some reason my onSubmit method is being called twice, the first time through things
are processed properly. However the second time through they are not; and the incorrect
information is being persisted.
I've also noticed that on other pages which are simply pulling information from the data
base and displaying on screen; Double requests are happening there too.
Is there something misconfigured, am I not using spring properly..any help on this would
be great!
Additional Information:
The app is still being developed. In testing the app I'm running into this problem. I'm using the app as I would expect it to be used (single clicks,valid data,etc...)
If you are testing in IE, make note that in some versions of IE it sometimes submits two requests. What browsers are you testing the app in?
There is the javascript issue, if an on click handler is associated with submit button and calls submit() and does not return false to cancel the event bubble.
Could be as simple as users clicking on a link twice, re-submitting a form while the server is still processing the first request, or hitting refresh on a POST-ed page.
Are you doing anything on the server side to account for duplicate requests such as these from your users?
This is a very common problem faced by someone who is starting off. And not very sure about the application eco-system.
To deploy a spring app, we build the war file.
Then we put it inside 'webapps' folder of tomcat.
Then we run the tomcat instance using terminal (I am presuming a linux system).
Now, we set up env in that terminal.
The problem arises when we set up our environment for the spring application where there can be more than one war files to be deployed.
Then we must cater to the fact that the env must be exclusive to a specific war file.
To achieve this, what we can do is create exclusive env files for every war. (e.g. war_1.sh,war_2.sh,.....,war_n.sh) and so on.
Now we can source that particular env file for which we have to deploy its corresponding war. This way we can segregate the multiple wars (applications) and their environment.