I am following the tutorial here:
http://nutch.sourceforge.net/docs/en/tutorial.html
Crawling works fine, as does the test search from the command line.
When I try to fire up tomcat after moving ROOT.war into place(and it unarchiving and creating a new ROOT folder during startup), I get a page with the 500 error and some errors in the Tomcat logs.
HTTP Status 500 - No Context configured to process this request
2009-02-19 15:55:46 WebappLoader[]: Deploy JAR /WEB-INF/lib/xerces-2_6_2.jar to C:\Program Files\Apache Software Foundation\Tomcat 4.1\webapps\ROOT\WEB-INF\lib\xerces-2_6_2.jar
2009-02-19 15:55:47 ContextConfig[] Parse error in default web.xml
org.apache.commons.logging.LogConfigurationException: User-specified log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable.
at org.apache.commons.digester.Digester.createSAXException(Digester.java:3181)
at org.apache.commons.digester.Digester.createSAXException(Digester.java:3207)
at org.apache.commons.digester.Digester.endElement(Digester.java:1225) ............ etc.
So it looks like the root of the error is default web.xml, not in the Log4JLogger - although I know very little about Java. I did not edit the web.xml in the tomcat dir.
Anyone know what is going on here?
versions/info:
nutch 0.9
Tomcat 4.1
jre1.5.0_08
jdk1.6.0_12
NUTCH_JAVA_HOME=C:\Program Files\Java\jdk1.6.0_12
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_12
In Java, applications sometimes rely on third party libraries. In this case, it appears that your Tomcat installation does not include one such library. Judging by the error you received, it appears that you are missing the Apache Commons Logging library (a commonly used library in the Java world that just so happens to not come bundled with Tomcat).
The typical way to distribute a library in Java is via a JAR (Java Archive) file. Simply put, a JAR file is simply a bunch of Java classes that have been zipped into a file that has been renamed from *.zip to *.jar.
To obtain the Commons Logging JAR file, you can download it from the Apache Commons download site. You will want the binary version, not the source version. Should you happen to download version 1.1.1 (for example), you should unzip the commons-logging-1.1.1-bin.zip file. Inside, you will find a file named commons-logging-1.1.1.jar. Copy this JAR file to the lib directory wherever your Tomcat software is installed. You may be required to restart Tomcat before it notices this new file.
Hopefully, the next time you try to use the application, you may or may not receive yet another error indicating that yet another class cannot be found. In that case, I welcome you to the wonderful world of JAR hunting! :) Hopefully the application will not require too many libraries above and beyond Commons Logging, but we will see (considering you're trying to run Nutch, I can foresee it requiring Lucene, so be prepared for that).
Have fun with Nutch!
For me that tells that it can't find the logger which is reported as a parse error itself. A bit odd or disinformant way to express it, I guess. Anyway, I think you need to add the Commons Logging .jar to your libraries (WEB-INF/lib) and restart Tomcat and then it should work.
Also your Tomcat seems to be ancient, if possible I'd recommend getting 5.5.x or 6.x.
if you found to have required .jar existing in application, than solution to your problem might be to:
Stop Tomcat
go to %TOMCAT_HOME%/work an erase everything inside
this 'work' folder, as its name says, contains classes used for work, sometimes access to some of these files can be blocked for any reason. When I get such message this is first thing to do. Most of the time it works...
Related
I can't get any pages of my webapp to load (locally on Tomcat 7.0.2.6), due to this NoClassDefFound error. I'm at my wits end trying to figure out what the cause is, here is what I know:
My coworker has this project successfully running locally (on Tomcat) and on our development server (WebLogic).
I have done a fresh pulldown from svn so my code is exactly the same as his. I've verified that I have a shared library reference to Aspose (and that the required .jars are in there), and that weblogic.xml has an entry for it.
We saw this same error when initially deploying on WebLogic because the Aspose library was named incorrectly, but it ran fine locally on his Tomcat server.
I've tried cleaning and rebuilding the project to no effect.
As best as I can figure, it has to be either a Tomcat issue, or maybe an Eclipse setting.
Has anyone encountered a similar situation? Any ideas on what to try to resolve this?
First thing you need to do is determine if you are colliding with another class with the same name and package. The easiest way to do this is with the cygwin/linux console, save this shell script to a file say, findjar
find "$1" -name "*.jar" -exec sh -c 'jar -tf {}|grep -H --label {} '$2'' \;
put it in your path and navigate to the root of the server instance and run the script like this
findjar . yourclass
Note the period, dont forget it. this will return if you have multiple classes with the same name in your project.
once your sure the project is clean and there is only one copy of the class, i would try actually adding your shared libraries folder to the websphere server instances JVM arguments. to do that:
Go into the admin, click on servers
Open server types, click on websphere application servers
You should see your server listed there, click on it
On the right hand side, you will see a section “server infrastructure” and below that is a subsection “Java and process Management”
Open that section and click on “Process Definition”
On the process definition screen is another right hand column. Click on “Java Virtual Machine”
Yes, finally we are on the correct screen, there is an end in sight here, I promise
On the virtual machine page, there is a large text field labeled “Classpath” What you need to do is enter the full path to the shared libraries folder
its odd and makes no sense to have to do it, but i have had to do that in the past to allow my code to see the properties files in a shared resource.
It is possible that your colleague has java librarys installed within his Tomcat instance itself.
Take a look in the Tomcat directory for some lib folders (I cant remember the exact location and I think it changes based on the version) but something like ${CATALINE_HOME}/common/lib
Verify that he doesnt have differen JAR files in his tomcat installation as yours.
From this question: Does Tomcat load the same library file into memory twice if they are in two web apps?
They are apparently stored here:
Tomcat 6 $CATALINA_HOME/lib
Tomcat 5 $CATALINA_HOME/common/lib
I have a small project created with IntelliJ IDEA, using Jersey.
I already created the server part working just fine and hosted on a GAE server.
I try to connect to it via a Jersey Client, and here comes the strange stuff.
Everything works fine if I run my application from inside the IntelliJ IDEA. However, once I run the jar JSON support seems to be gone, however XML works. Any ideas?
I feel I need to mention that the jersey-json is packaged with the generated jar.
Here it is the jar file in question. You'll need both the jar and the dll file, one near the other and just run it.
The Console Output (Error): https://docs.google.com/open?id=0B42XvjSlpDCtTTdwQl9MSTBlQ0U
The JAR file I used (all dependencies extracted into it). Any JRE6 may run it. https://docs.google.com/open?id=0B42XvjSlpDCtTVNUQTQ4SXFCcDg
The DLL required for the JAR (although, it should work without this too): https://docs.google.com/open?id=0B42XvjSlpDCtNXpabVk5RDkyRW8
And here's the source code on the github (public): https://github.com/gaborbernat/fs_viewer
Finally, I attach a picture with the settings of the artifact (JAR) generate rules.
Thanks for your support, :)
please see http://java.net/projects/jersey/sources/svn/content/trunk/jersey/jersey-tests/src/test/java/com/sun/jersey/impl/json/ListOfJAXBBeanTest.java?rev=5698
(your usecase can be extracted from there; the point is that you need to configure Jersey Client to be able to handle json by a) registering JAXBContextResolver or b) explicitly adding MessageBodyWriters (jackson))
And dont forget to use GenericEntity (as in linked test).
I would like to know what are the pros and cons, if any, of injecting or dropping java class files into an exploded ear file that is deployed in WAS 7.
When we install the packaged ear file it gets exploded into a certain temp directory and we can actually go into the folder location of the class file and replace it with our new class file and restart the server to load it.
If we are doing it for every node in WAS 7 and restarting them one by one for HA. would there be an issue.
Thanks.
Syed...
Here's another con to worry about. If you replace the file on the node and DMGR doesn't know about it, if you do a full sync the file from the DMGR will be pushed out to the nodes.
The recommended way to do this is to properly get the new file in the EAR and do another deployment.
You might encounter problems if the class contains annotations since application deployment caches the result of annotation scanning. Otherwise, you might be able to get it to work, but I doubt you would get support from IBM if something breaks. The supported mechanism for what you're trying to do is available via AdminApp.update in wsadmin.
I have a simple hello, world servlet application that I am just playing around with, and pushing it out to my tomcat server on a VPS.
When I make a change to my code, and deploy it, tomcat doesn't serve the newly published code (even after starting the service again).
I stop the service, then push the new war file to /webapps/, and I make sure to delete the old exploded folder also.
When I re-start the server, it still serves the older codebase.
Is there a setting in the config to stop this behaviour?
Also, what folders would I have to delete? Please be specific (folders and paths) as I have tried deleting some and havent' gotten anywhere.
You can delete the "work" directory.
Are you sure it's not a browser caching issue?
I'd add that in case of really odd behavior - where you spend a couple of hours saying WTF - try manually deleting the /webapps/yourwebapp/WEB-INF/classes directory. A java source file that was moved to another package will not have its compiled class file deleted - at least in the case of an exploded web-application on TC. This can seriously drive you crazy with unpredictable behavior, especially with an annotated servlet.
A little late for the party, here's how I do it
Undeploy application from manager
Shutdown tomcat using ./shutdown.sh
Delete browser cache
Delete the application from webapps, and from /work/Catalina/...
Startup tomcat using ./startup.sh
Copy the new version of the application into /webapps and start it.
I encountered some weird behaviour that did not reflect the actual code base so after some time trying several solutions, my problem was solved by manually deleting everything under /var/cache/tomcat8/
Seems a timestamp issue. According to tomcat documentation, if there is a new jsp or servlet this will create a new _java file in the work folder unless the _java.class files are newer than the jsp or servlets.
Tomcat also creates a ROOT directory at the same level as work/. ROOT/ also caches the old stuff. delete ROOT along with Catalina directory in work.
I'm new to tomcat, and this problem was driving me nuts today. It was sporadic. I asked a colleague to help, and the WAR expanded and it did was it was supposed to. 3 deploys later that day, it reverted back to the original version.
In my case, the MySite.WAR got expanded to both ROOT AND MySite. MySite was usually served up. But sometimes tomcat decided it liked the ROOT one better and all my changes disappeared.
The "solution" is to delete the ROOT website with every deploy of the war.
Sounds like your class loader is not loading the servlet classes once they are updated. This might be fixed if you change your web.xml file which should prompt the server/container to re-deploy and reload the servlet classes.
I guess add an empty line at the end of your web.xml and save it and then see if that fixes it. As i said this might fix it or might not.
Good luck!
I have a bad time putting my war file at /etc/tomcat7/webapps but the real path was /var/lib/tomcat7/webapps. May you want to use sudo find / -type f -name "my-war-file.war" to know where is it.
And remove this folders /tmp/hsperfdata_* and /tmp/tomcat7-tomcat7-tmp.
I had the same issue twice, but in the second time I realized it wasn't a problem on Tomcat at all.. Try to delete the cache of your browser, refresh the page and see if the new version of the page on your server is being shown up. It worked with me.
In folder "/webapp" delete *.war files and folders corresponding to these
folders(the same name).
Clear folder "/webapps/ROOT" tomcat.
I'm currently working on a prebuilt application running on weblogic.
The application consist in NAME_APPLICATION.jar that must be deployed on weblogic.
My problem is that I can't analyze anything for the simple reason that the jar DOES NOT CONTAIN ANY .JAVA OR .CLASS FILE
The jar just contain the following files:
- APPLICATION_1.0.sources
- APPLICATION_1.0.space
- APPLICATION.ws
- GET_SOMETHING.ds
- GET_SOMETHING.service
I really don't understand it. Where is the application ? How weblogic knows the logic (forgive me the pun) of the app? How to edit the application and where is the source files?
It's the first time that I see such Jar file, it's probably because I'm a weblogic beginner
Thanks
These are resources that must be available on the classpath for the application to find them and access them. I am guessing that the documentation tells you to deploy it as a shared library.
If they are binary files (not text files that you could try reading with a text editor), then whatever application needs them obviously knows their format and how to read them.