I have a requirement that I need to use a single server machine to run 2 totally different applications.
The server machine has Apache Tomcat 6.0 installed. 1 of the applications is deployed on it and is running successfully for a long time. Initially, the clients used to connect to it by invoking the url "http://machine-name/1stProjectName/initialPage". I have also mentioned the "initialPage" as the Welcome Page in web.xml of this project. But somehow, later some ports or relating things were changed by the server maintenance team, and to connect to the application, now one has to use the url "http://machine-name" or "http://machine-name/initialPage", i.e. the machine name has started behaving like the project name folder because now if I invoke the url "http://machine-name/1stProjectName/initialPage", it gives 404 error saying that "/1stProjectName/1stProjectName/initialPage" resource not available.
Now, when I deploy the WAR of the second application into the webapps folder of Tomcat (just like I did for the first application), it unpacks it properly. But, the issue is how do I connect to this second project. If I use "http://machine-name", it takes me to the 1st application and if I use "http://machine-name/2ndProjectName/initialPage", it gives me an error that "/1stProjectName/2ndProjectName/initialPage" not available.
Kindly help or guide me in some direction.
Thanks in advance.
Your URLs should look like this if you did things properly:
Project 1: http://host:port/war-name-1
Project 2: http://host:port/war-name-2
That means no changes to content.xml to modify the path.
I would talk to your "server maintenance team" and let them know what you are trying to do (since they are the ones who made these changes in the first place). But it sounds to me that they just mapped a path to a specific location, that is your machine-name root is mapped to 1stProjectName.
Related
I have a filter used for authorization. It's the first step entering application. Without it is not possible to do anything in the application.
I set a systemout on the very first line of doFilter method to monitor the behaviour, so comparing websphere server log files I'm sure that filter (same Ear deployed) on Test environment works and on Production environment not.
Maybe it's server configuration issue...?
I have access to read and modify WAS Console of test environment.
I have access only to read WAS Console of production environment.
So I can compare them, and maybe test some change on test environment to replicate the behavior and say to production administrator what exactly setup....
Any suggestion on which setting I can check (Was console, maybe in relation with Web.xml, etc...)?
Thx a lot for any suggestion.
EDIT
I was able to retrieve via FTP the EAR in InstalledApps of Production environment. I noted a file named "web_merged.xml" in which is missing the entry of the filter.
Maybe the problem is here? When is created and why? Why could be missing the entry there? How let WAS to create the right file (if the problem is there)?
The problem was the one on the EDIT in the question, webmerged.xml was wrong. We weren't able to understand why WAS generated this file in wrong way.
What I understand is generated during deploy and is a mix of web.xml of the applicatin with application server configuration.
That's a WebSphere issue, we guessed it has to do with application server cache. We asked to System Administrator to:
Uninstall the application
Stop the server in which the application was installed
Clear the cache
Restart the server
Reinstall application
From this point the file was generated in the right manner, as the application bahaviour.
Websphere version is 8.5
Im working on a Tomcat application. I just updated from Tomcat 7 to Tomcat 8 using the migration guide.
After I did this, I recognized that the context path of the applications deployed on the server behaves different now.
I am requesting the context path in a jsp. deployed in the ROOT directory using:
application.getContext("app").getContextPath()
The result is the context path of the application: /app
The context path is always the same, if the application is running or stopped.
After upgrading to Tomcat 8.0.33 the behavior is different.
When the application is stopped, the context path that I get is an empty path (which results in pointing to ROOT).
The context path of the runnnig application is still the same: /app
I studied the migration guide and change log but I did not find any change which explains the different behavior.
I also googles a lot and have no clue what explains this behavior.
Can anybody help me finding out what the problem is?
I think I did not clear enough explain what I am doing. I do not want the current context path of the application.
On the Tomcat are various numbers of applications deployed (let the names be /app1, /app2, ..., /app10). Inside the jsp, deployed in ROOT, I want the to find out which applications are actually deployed on the server. I am doing this by asking for the ServletContext of the other applications:
application.getContext( "/app1);
application.getContext( "/app2);
...
When I then asking for the context path of the application it is either empty (application is not deployed) or I get the actual path (e.g. /app1) for a deployed application (started or stopped):
application.getContext("/appX").getContextPath()
Thats how I create a list of deployed applications.
But now on Tomcat 8 I get an empty context path not only for applications which are not deployed, but also for applications which are deployed but stopped. This is a different behavior as it was on Tomcat 7.
I hope I could make clearer now what´s my problem.
Unfortunately I could not find out what´s the issue. Instead I rewrote my code to use the tomcat manager endpoints.
I had deployed an application in the application server Apache
Tomcat. My GWT application needs to access files in folder "C:
\Storage". In development mode the application runs like a charm but
in an external web server (Apache Tomcat) it does not run, crashes
when it tries to copy files from "C:\Storage" to "\docs". I think this
might be because i'm trying to access files outside the webroot. How
can i solve this situation? Using apache commons libs to deal with
files? Could be permissions? I need some enlightment, some help will
be very apreciated.
Thanks in advance,
João Cavaleiro.
Another (wild) guess: if you deploy wars without unpacking as real files, getRealPath("/doc") will return null. (You have no files inside a war). So you have to configure Tomcat:
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
upackWAR = true
Thanks you all for the replies. I actually figured out what the problem was: Paths.
"\docs" is the folder located in the root of the app.
Unfortunately Apache didn't wrote any exception on catalina.out log (the code catch the exceptions ocurred).
Simply i didn't create a new File(pathname) with the absolute path of the destination location, i was using only the "docs/filename.txt" assuming that the File classe would recognize the full path, "knowing" the location in the filesystem of the app. I assume that this is a situation to keep in mind with sepecific application servers because with eclipse/Jetty it works but with Apache Tomcat don't (I am developing a GWT application).
But in the matteer of fact, the debbug was not easy, the debbug mode with external server didn't work in the server side in the peace of code where i it's needed to do this io operations strange), and the System.out.println that i managed to help me figure out the problem didn't show up in the catalina.stdout (strange to and yes, i have compiled and deployed it on the Apache Tomcat with that modifications twice).
Thanks to everyone.
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 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.