A Web application running fantastic (as expected/planned) on Eclipse (Indigo); but a particular functionality1 fails while deployed on Tomcat 6.0.
I had changed the environment settings of Tomcat as on Eclipse, but unfortunately it's still not working.
And the strange thing is that; while running in Eclipse the temp directory for Java is TEMP folder2 of the User; where as while running on Tomcat the temp folder becomes WINDOWS\TEMP and that why new file couldn't be found and hence exception FileNotFound is getting fired. Why does this happen?
[1]: It's calling a non-Java application to convert files that are being uploaded to server.
[2]: Used for the aforesaid non-Java application for the file conversion.
Tomcat, when installed as a Windows service, is running under a different user account and thus uses different paths. Especially when running as system service there is no user directory. If you have a controlled environment you should set fixed paths, e.g. per environment variables or properties files, that both applications can share.
Related
I am working with Intellij but some of my co-workers don't. When I was writing install doc, I realized that Tomcat is not managed the same way on the two IDEs.
Which is a problem considering what happened next when I tried to set up our project on Eclipse.
Basically, on Intellij, you select a Tomcat on your computer and it will literally copy the war into the webapps folder and run the server with everything working fine.
I am not a user of Eclipse so I might have misunderstood something, but I found that when you create a Tomcat server, it will embed the one you gave it to it. Doing that is a bit of an issue when you are working with logback, because usually you set your logs location directly into the Tomcat folder. And in Eclipse you are working out of this folder.
So, I can't run my application because it can't find the location of the logs folder at the fine place.
Is there a way to use Tomcat in Eclipse like Intellij? Or did I just miss something because I am kind of new with Eclipse?
See the FAQ: (1) (2)
I found that when you create a Tomcat server, it will embed the one you gave it to it.
You have to be more specific with your description. How you do things and what do you see. What do you mean by "embed"? What is the actual failure that you are observing with your logging?
There are different ways to do things.
For me by default Eclipse does not embed Tomcat, but runs it as a proper java process. (org.apache.catalina.startup.Bootstrap) You should be able to see it with jconsole and similar tools.
It runs your web application expanded, i.e. without zipping it into a war file. It creates a separate configuration of Tomcat, i.e. runs it with separate CATALINA_HOME and CATALINA_BASE directories (as documented in RUNNING.txt file of Apache Tomcat). The CATALINA_HOME directory stays untouched and CATALINA_BASE directory is ${workspace}/.metadata/.plugins/org.eclipse.wst.server.core/tmp0 etc. A logs directory can be found there.
One known caveat is that java.util.logging is not configured by default (the system properties java.util.logging.manager and others are not set). See "How do I enable the JULI logging" item in the FAQ. -- In the same way you will set any other system properties that you may need.
The default configuration of java.util.logging (as provided by JRE) is to log everything to the console, without creating any files.
I'm working on a WLS 12.1c locally installed application server (on a VM instance). I deployed apps with the help of the WLS web console. Selecting "install" and selecting the path of the EAR file I wish to deploy. Fine. Works.
However, I wish that the ear is picked up from this same place every time it changes. Otherwise I have to "Delete" the deployment package, restart the server and "install" the EAR again. Too much hassle.
How do I activate auto-deployment?
thanks
If you're in a development setting, you might want to use auto-deployment instead:
Development mode enables a WebLogic Server instance to automatically deploy and update applications that are in the domain_name/autodeploy directory (where domain_name is the name of a WebLogic Server domain).
Note that your Weblogic Server MUST be running in development mode.
Once you add your EAR to domain_name/autodeploy/, from there on out, it will automatically picks up changes to the files in that directory:
To auto-deploy an archived application, copy its archive file to the /autodeploy directory. WebLogic Server automatically sets the application's deployment mode to stage mode.
A deployment unit that was auto-deployed can be dynamically redeployed while the server is running. To dynamically redeploy, copy the new version of the archive file over the existing file in the /autodeploy directory.
See: http://docs.oracle.com/cd/E24329_01/web.1211/e24443/autodeploy.htm
I'm using GWT 2.4 and have a ton of code already written. I understand the Jetty server that comes with the GWT plugin has very tight control over the jars that can be used in a project to mimic app engine as closely as possible. I need to deploy to tomcat 7. I modified my project in eclipse and "blessed" it as a dynamic web project so I can export...WAR and upload it to my QA and production tomcat.
I need help with getting the app to run (and debug) on an embedded tomcat (like an honest dynamic web project would). I already have tomcat setup in eclipse and I have my CAS server web app deployed to it.
I've ready tons of either old or confusing posts here and elsewhere. Basically, I'm looking for the same debugging environment I would get with the packaged Jetty server, but on my own tomcat configured with WTP in eclipse...so I can mimic my production environment (just like Jetty mimics app engine)
any help is appreciated.
It should probably a little bit easier, but it's possible. Here's how I do it:
1. Setting up the web server
Using the JavaEE edition of Eclipse, I set up the Tomcat 7.0 server adapter, and define an environment in Preferences > Server > Runtime Environments
File > New > Project... > Web/Dynamic Web Project
Select the target runtime I set up in the first step
Important: In Context Root, enter /
I create an HTML file and a Servlet, and then try running the setup using Debug As > Debug On Server
2. Adding the GWT code server
Project > Properties > Google > Web Toolkit > Use Google Web Toolkit
Important: I always need to change the order in the Java Build Path (Project > Properties > Java Build Path > Order and Export), see http://code.google.com/p/google-web-toolkit/issues/detail?id=4479 - gwt-dev.jar must be pretty much on top of the path.
Project > Properties > Google > Web Application: War directory = "WebContent", also check "Launch and deploy from this directory"
I create some sample GWT content (I create a sample GWT project, and copy most of it over)
I try to GWT compile the project. This shows me, if I got the build path order right - otherwise, the compiler fails early with "java.lang.NoSuchFieldError: warningThreshold".
Debug As > Web Application - just to create a debug configuration. Stop the debug. Edit the debug configuration (Run > Debug Configurations...), deselect "Run built-in server". Start the debug again.
Now, finally, I can debug both the server and the client part (I still need to click two Debug icons to start both!) I can manage the client side from the "Development Mode" view, and the server side from the "Servers" view. At the end of the day, it works great, and using the "Automatically publish when resources change" feature (Servers view > myServerName > Open > Publishing), sometimes even better than with the integrated Jetty.
At first thought, I don't really see why you would be facing a problem. Perhaps, the way Eclipse is laid out is too confusing and daunting.
On my Eclipse, I had been using the default jetty as the server during GWT debug. However, there were some problems which would not be caught by jetty when deployed on Tomcat or JBoss.
And when I added Tomcat or JBoss instances to Eclipse and added my app to those server instances, the debugging worked straight away. Are you missing one piece of vital, but simple info?
Let me presume that the following would fill in your missing link ...
Locating/adding your server instance:
On Package Explorer (or Project Explorer, either one) in Eclipse, you would see, besides your personal projects, a "servers" project. Under it is are configuration nodes listing all your Tomcat instances.
If you cannot see the "servers" node in Package Explorer, it probably is due to your working set filter. (And if you don't know what working sets are ... I guess you would need to beef up on your dexterity in Eclipse).
If you don't already have a Tomcat instance, you simply right click on the "servers" project to add a new server (Package Explorer -> New -> Server ...). You would be asked the location of your Tomcat home. And your desired port number of the server instance. Of course, you would have to ensure that the port number will not clash with the port used by any other inet operation on your box.
Configuring the port number a 2nd time
On the server instance node in Package Explorer, you would find the file you should edit to set the port number to match the one you specified when creating the new Tomcat instance. If you don't know which file to edit, you would need to read up on the Tomcat version you created to find out which file contains the port number config.
You need to config the port a 2nd time because the 1st time tells Eclipse where and at what port to expect the server instance to be running. The 2nd time is to configure the server instance itself.
Adding your app to the server
However, the nodes in "servers" project only allow you to configure your Tomcat instances. There is yet another view called the "server view" to further configure your tomcat instance. You need to enable Server view from Window->Show View->Server->Servers.
Right click on the server instance in the "Server View" to add your app.
Running debug off the Maven generated target.
There are times you wish to debug the war structure to figure out which jars are missing in the war. And incrementally remove jars from your war to figure out the jars that are already supplied by the server. Since JBoss supplies many of the jars already, you would have to figure out if your development jars are of the versions as those expected by JBoss.
You would create another Eclipse project in your workspace and make an Eclipse folder softlink in your 2nd project to point to the Maven generated target of your first project. And you specify target/{maven generated webapp directory} as the webapp directory of your 2nd project. What I mean by "maven generated webapp directory" is the unzipped intermediate directory generated by Maven (used by Maven to generate the zipped war file).
This is the cleanest way to debug production war if you could faithfully replicate the production tomcat/jboss server on your Eclipse development box.
If you prefer JBoss.
Somehow, JBoss config node is not listed in the "Servers" node in Package/Project Explorers. You would need to go to your JBoss installation directory to edit them.
Remote debugging.
If you wanted to debug the app on your production box, or on a server sitting on another box, you would have to start that tomcat instance under debug. You should read up on that. You have to specify the debug port.
Then in Eclipse, at Run->Debug Configuration->Remote Java Application, you specify the app and the debug port.
The first time you debug, Eclipse "may not know" where the source files are, especially if your app has multiple project dependencies. (Why can't Eclipse search the source files from my list of projects?) Anyway, you have to specify where to find your source files. And then when your debugging traverses into another project dependency, you would have to over-write the location of the source files.
So, voila! That is how I got my debugging working. I advise you to avoid remote debugging as much as possible unless you need to diagnose production problems. Unless you are doing remote debugging, do not attempt to deploy the war to local server, but simply depend on associating the project to the server instance.
Eclipse is too confusing
I know Eclipse is too confusing and you have to wade thro its features. You just have to bear with it. Eclipse menus & views are apparently optimized for plugin-programmer-centric not user-centric.
For example, why would I go to "help" to install new software? I used to expect that "Help->Install new software" to be an instructional manual to installing new software.
It beats (and annoys me) that the Eclipse team did not combine the operations together so that I could add apps to a server instance at Package Explorer. Why not? As a user I would expect to see only a single entry point to configuring my servers.
To alleviate the confusion, I like encouraging people to download and install Springsource's version of Eclipse (STS). It's the same Eclipse, except that STS has the essential parts installed and has a dashboard pointing to compatibly installable plugins. Tomcat is preinstalled as VMware tc Server. And the views are correctly config'd to show the server instances. And the correct workable Eclipse-Maven bridging plugin is pre-installed.
I have an exploded directory that I am editing in eclipse (created via setting location to directory location when creating New Project, deployed directory already existed). When I deploy this directory from the command line, it does not seem to save it locally (anywhere within glassfish\domain_
If I create a Java EE application in eclipse from scratch and deploy it from Eclipse Run -> on server, it copies it to glassfish\domains\domain1\eclipseapps
Is there a way to have GlassFish save deployed directories locally without using the GlassFish plugin magic?
Short Answer: No.
The whole point of directory deployment is speed and development convenience.
You tell GlassFish to not copy any files at all but to, instead, use the files already laid out on disk.
If you want to run from a copy of your app then just deploy the archive (war/rar/ear/jar) file.
I have created myProj.ear file and copied it into the deploy folder of the JBoss server.. How to run my project after starting the jBoss server?
I have been using war file and
deploying it in Tomcat till now to run
my project.... I am having a new
requirement to run the project in
JBoss. So, I converted my war file
into an ear file using the command Jar
-cvf myProj.ear ., Should I change anything in my project to run
the application in JBoss or just
copying my .ear file in to the jBoss
deploy folder is enough?
JBoss normally support hot deployment - meaning that if your application was deployed correctly (watch the console), it can be accessed via the browser (if you have a UI) or via web services, managed beans or any other interface you have provided.You can see the status of your application on the JBoss Admin Console. You can reach it by typing the URL of your JBoss installation. If you run your vanilla JBoss locally, you should be able to find the console under http://127.0.0.1:8080/admin-console
To reiterate: there is no explicit startup necessary, JBoss handles it for you.
Deploying an application in JBoss is pretty straightforward. You just have to copy the EAR file to the deploy directory in the 'server configuration' directory of your choice. Most people deploy it to the 'default' configuration, by copying the EAR file to the JBOSS_DIR/jboss-as/server/default/deploy directory.
Once copied, just run run.sh from bin, you can use the following params to bind it to an ip (-b) or binding it to anything other port (-Djboss.service.binding.set)
./run.sh -b 9.xxx.xxx.xxx -Djboss.service.binding.set=ports-01
Once you run it, Look at the console for error message. If everything goes fine you'd see "Started J2EE application" after couple of seconds.
If there are any errors or exceptions, make a note of the error message. Check that the EAR is complete and inspect the WAR file and the EJB jar files to make sure they contain all the necessary components (classes, descriptors,
jboss-deployment-structure.xml etc.).
You can safely redeploy the application if it is already deployed. To undeploy it you just have to remove the archive from the deploy directory. There’s no need to restart the server in either case. If everything seems to have gone OK, then point your browser at the application URL.
http://localhost:8080/xyz