I have an Eclipse Project which is attached to a Tomcat 6 using WST. For testing reasons I need to set some context parameters to override settings in the web.xml. The following Server Options are set: "Serve without publishing" as I want to run my application right from the project and "Publish contexts to separate XML files".
Now I can find the context fragment inside .metadata.plugins\org.eclipse.wst.server.core\tmp1\Conf\catalina\localhost and change them as needed. This works for some time, but after each Eclipse restart my context fragment is replaced with a fresh generated one - without the required parameters of course.
How can I prevent Eclipse from replacing my configuration? Or is there a way to add the necessary parameters to the generated context fragment?
Certainly changing stuff in the .metadata/.../wst.server is not a good idea - those directories are completely controlled by Eclipse.
If you look in your Eclipse 'Servers' project entry, you will see server.xml and context.xml - that is the place to change things. Eclipse copies those files to that .metadata directory - IF it isn't fouled up somehow.
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 using Tomcat 8.5.6 inside Eclipse 4.6.1. I have my web-app project/context foo, which has a JAX-RS (using RESTEasy 3.1.0.CR3) endpoint of bar, so I can fire up Tomcat inside Eclipse and access:
http://localhost:8080/foo/bar
I have a variable named foobar which I want to access inside my JAX-RS implementation using JNDI:
final String foobar = (String) new InitialContext().lookup("java:comp/env/foobar");
I plan on deploying the produced WAR in production using Tomcat autodeploy. I want to configure the foobar variable for Tomcat externally to the WAR. How can I do that so that I can test it in Eclipse?
After a lot of reading, I found what I thought to be the $CATALINA_HOME of Eclipse: …\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\. So I created a context file for foo at …\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\conf\Catalina\localhost\foo.xml to correspond to my project/context, and put the following inside it:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Environment name="foobar" type="java.lang.String" value="123"/>
</Context>
Yes, I know that Eclipse erases this directory whenever I rebuild. But after building, I saved to file at least want to see if it works. It doesn't. I get an error:
javax.naming.NameNotFoundException: Name [foobar] is not bound in this Context. Unable to find [foobar].
I want to at least get it working so I can know how to do this in production, and worry later about the context file deletion thing in Eclipse. So what did I do wrong? Why can't Tomcat in Eclipse find this JNDI variable?
Note: I am not using a web.xml file and have no desire to do so; besides, this variable should be defined outside the WAR in the production deployment.
Update: The good news is that (on Windows 10 Professional Anniversary Edition 64-bit) using the same Tomcat but in standalone mode, I put the same foobar.xml file inside the standalone Tomcat's conf\Catalina\localhost\foo.xml, and my JAX-RS application picked it up just fine. So how can I define a JNDI variable in Tomcat inside Eclipse for testing?
It appears that in order to get Eclipse+Tomcat to recognize the per-module context files, you have to go into the server configuration (double-click on the server) and turn on the Publish module contexts to separate XML files. This way Tomcat will use the specific context XML file you created. Otherwise it apparently puts them in conf/server.xml and ignores the context-specific file you created.
There is still the problem that Eclipse regenerates this file each time you do a rebuild, destroying whatever JNDI variables you placed there. I'm trying to get the workaround in https://stackoverflow.com/a/22380248/421049 to work, but not yet succeeding. Anyone have any better ideas?
At least I'm able to reproduce a production environment now --- albeit temporarily, until the next rebuild.
Your link to Markus' answer on https://stackoverflow.com/a/22380248/1794485 allowed me to get this working, or at least as described in his workaround. But the remaining problem to solve was ordering.
As he said, you can workaround this by having a local copy of the META-INF/context.xml somewhere else, and adding this folder to the Deployment Assembly in the project properties of the Eclipse project.
This didn't pick up for me initially though. It looks like that while the Deployment Assembly in the properties shows as sorted by name, in fact it has an order like any other path. When I then removed the src/main/webapp entry (so the one containing the normal META-INF/context.xml) and added it back in, this effectively moved it down the pecking order. The next Tomcat deploy and startup in Eclipse finally put my preferred copy of META-INF/context.xml in .metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\myapp\META-INF
If in doubt about the true sequence of that Deployment Assembly path, have a look under your Eclipse project on the file system - at .settings\org.eclipse.wst.common.component.
How can I make sure that the server.xml which Eclipse produces for every separate project that relies on Tomcat, will always contain a specific option, which I added manually?
I'd like to add a bunch of <Context> mappings to the server.xml file. I tried doing that in the server.xml in the main tomcat dir - didn't work.
Then I saw that Eclipse builds a temporary folder for every project that uses Tomcat. This folder also containes this server.xml file. I edited it, and voila, it worked. However, soon after that the same file got updated by Eclipse, with the original data that it contained.
It is not very efficient to manually copy and paste the code every time before I run/restart tomcat. I hope there is a more permanent way.
Let's assume you have configured tomcat 5.5
If you have configured your tomcat server in eclipse using all default options, you want to edit the server.xml located at WORKSPACE_LOC\Servers\Tomcat v5.5 Server at localhost-config\server.xml
I'm going to try to give as much detail as possible here, pardon me if some is irrelevant.
I have two projects in eclipse. Project 1: com.myworkplace.parent, with code in the package of the same name. Project 2: com.myworkplace.child, with code in package of the same name (I moved my code to that package, from the default package, if that makes a difference). Both are located in my workspace folder and structured the way you'd expect them to be, as far as I can tell.
I've added child to the build path of parent in eclipse using Java Build Path -> Projects -> Add. Parent's .classpath file contains the entry:
<classpathentry combineaccessrules="false" kind="src" path="/com.myworkplace.child"/>
I add a reference to a com.myworkplace.child.Child class in parent, import it, compile it with no errors, run and get:
java.lang.NoClassDefFoundError: com/myworkplace/child/Child
What gives?
Edit: The parent application is an RCP app, maybe OSGI (I really don't know much about RCP and related stuff.) Some googling leads me to believe it might have something to do with this.
Since your application is an RCP app there is a difference between the eclipse classpath that is used while you are editing code and the OSGi classpath that is used at runtime. It sounds like you need to add the com.myworkplace.child plugin to the list of dependencies of the com.myworkplace.parent plugin.
Open either plugin.xml or META-INF/manifest.mf in the parent project. Eclipse should open the PDE plugin editor (a form based editor for the underlying config files). Click the Dependencies tab at the bottom and add your child plugin to the "Required Plug-ins" list on the left hand section of the form. Alternately you could add the com.myworkplace.child package to the "Imported Package" list on the right. The difference between the two is beyond the scope of this answer, but you can read about that in the eclipse docs now that you (hopefully) are moving in the right direction.
We found that even doing all the proper things in the eclipse rcp project, we were still getting such errors. The solution was to delete the application's workspace directory (by default it would store workspace settings under .eclipse, but we've tweaked our code to use another dir that is not shared with other eclipse stuff).
When we removed this dir after a rebuild, our app worked. Apparently it was storing the classpath somehow along with other settings, but we didn't investigate the exact details.
(NOTE: This applies only if you've called the IWorkbenchConfigurer.setSaveAndRestore method passing a boolean value of 'true' - which means that your application will save and restore various rcp settings after a shutdown of the application and subsequent relaunch.)
If your code is running in an application server, you need to configure the Classpath correctly for that application server.
To do that, find your Servers tab, double-click it, click Open Launch Configuration in the new tab that appears in the main editing area, click the Classpath tab and ensure the Classpath there is correct.
I'm using Eclipse and Maven-2 and I'd like to be able to edit my HTML files without "it" (not sure if it's Eclipse or Maven) recompiling my application. I understand that usually Eclipse tries to do a hot replace of new compiled Java classes with Eclipse and Tomcat.
Can I use something like this?
getResourceSettings().setResourcePollFrequency(null);
I know I can turn auto update off for Tomcat in Eclipse but I'd like the HTML file to update and the classes not to update if possible.
BTW, my primary concern is that Tomcat tends to get Perm gen errors after I (hot) reload too many java classes.
You're sort of correct, you're supposed to use setResourcePollFrequency(Duration.ONE_SECOND); or similar. This link has more detailed information. However what I've found is that due to Wicket's caching internal cache containers like to get really messed up after any hotswapping so you may just have to learn the hotkey for restarting Tomcat or start doing Wicket development with the integrated Jetty and WicketTester.
You may want to consider increasing the permgen space when you run eclipse. There is a command line argument:
eclipse [normal arguments] -vmargs -XX:PermSize=64M -XX:MaxPermSize=128M
(copied from:)
http://wiki.eclipse.org/FAQ_How_do_I_increase_the_permgen_size_available_to_Eclipse%3F
I am not sure offhand how to prevent wicket from reloading HTML files but I will see if I can find it.
Edit:
If setting the poll frequency to null doesn't work, try using Duration.MAXIMUM. Also, you can uncheck "Build Automatically" in the eclipse Project menu, though this is more of a hassle then it's worth, IMHO.
According to the wicket FAQ, wicket only reloads changed markup files when you explicitly set the resource poll frequency:
http://www.wicketframework.org/faqs.html
I am not sure how to prevent eclipse from copying altered files to the output aside from disabling build automatically.
If Build Automatically is enabled (it is by default: Project->Build Automatically) then any modification to the project files will trigger the build, regardless of whether they are in source folders or not.
I always work with Build Automatically disabled as I find it too intrusive (for reasons like this), and just hit ctrl-B when I want the project to build, or alt-P N to launch the clean dialog if needed.
I understand you're using (and might want to keep using) Tomcat, but during Wicket development you can run the supplied Jetty server onder /src/test/java/com/your/package/Start.java in debug mode to get this behaviour.. Set Wicket to development mode to use this feature.
HTML files or jsp files?
Are you using tomcat? If you are editing only html files, go ahead and change them as you wish. As long as you don't deploy them somewhere else for tomcat to fetch them, you'll see the update(s).
If it's jsp, save your new file, delete the files under the old work folder. This will make tomcat think it's the first time the file is requested and it will re-compile the jsp on the fly.