I'm looking for a few days for the solution to an UnresolvedAddressException I can't figure out!
It seems it's quite a challenging problem, since I couldn't even find other info on the net!
I'm working with OSGi framework on JamVM.
I get this exception when using Date.toString o SimpleDateFormat on a Calendar object. I can't understand why the bundle tries to connect after the getZoneStrings function. It seems it cannot find the locale but I'm not sure this is the problem.
I tried adding the file /etc/timezone (that was missing) but it didn't solve the problem.
Here's the complete stack trace of the exception:
adsdebian:/usr/local/bundle# org.osgi.framework.BundleException: Activator start error in bundle zApp_RoadPricing [24].
at org.apache.felix.framework.Felix.startBundle(Felix .java:1506)
at org.apache.felix.framework.BundleImpl.start(Bundle Impl.java:774)
at org.apache.felix.shell.impl.StartCommandImpl.execu te(StartCommandImpl.java:105)
at org.apache.felix.shell.impl.Activator$ShellService Impl.executeCommand(Activator.java:291)
at org.apache.felix.shell.remote.Shell.run(Shell.java :109)
at java.lang.Thread.run(Thread.java:743)
Caused by: java.nio.channels.UnresolvedAddressException
at gnu.java.nio.SocketChannelImpl.connect(SocketChann elImpl.java:160)
at gnu.java.net.PlainSocketImpl.connect(PlainSocketIm pl.java:281)
at java.net.Socket.connect(Socket.java:454)
at java.net.Socket.connect(Socket.java:414)
at gnu.java.net.protocol.http.HTTPConnection.getSocke t(HTTPConnection.java:719)
at gnu.java.net.protocol.http.HTTPConnection.getOutpu tStream(HTTPConnection.java:800)
at gnu.java.net.protocol.http.Request.dispatch(Reques t.java:291)
at gnu.java.net.protocol.http.HTTPURLConnection.conne ct(HTTPURLConnection.java:219)
at gnu.java.net.protocol.http.HTTPURLConnection.getHe aderField(HTTPURLConnection.java:582)
at java.net.URLConnection.getHeaderFieldInt(URLConnec tion.java:426)
at java.net.URLConnection.getContentLength(URLConnect ion.java:302)
at gnu.java.net.loader.RemoteURLLoader.getResource(Re moteURLLoader.java:79)
at java.net.URLClassLoader.findResources(URLClassLoad er.java:720)
at java.lang.ClassLoader.getResources(ClassLoader.jav a:640)
at gnu.classpath.ServiceFactory.lookupProviders(Servi ceFactory.java:286)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.ja va:163)
at java.text.DateFormatSymbols.getZoneStrings(DateFor matSymbols.java:123)
at java.text.DateFormatSymbols.<init>(DateFormatSymbo ls.java:192)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat .java:448)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat .java:430)
at crf.opengate.app.roadpricing.RoadPricing.<init>(Ro adPricing.java:109)
at java.lang.reflect.Constructor.constructNative(Nati ve Method)
at java.lang.reflect.Constructor.newInstance(Construc tor.java:328)
at java.lang.Class.newInstance(Class.java:1154)
at org.apache.felix.framework.Felix.createBundleActiv ator(Felix.java:3341)
at org.apache.felix.framework.Felix.startBundle(Felix .java:1453)
...5 more
Is there anyone who could help me, please?
Thanks,
Andrea
Add to andre26's Reputation
Found this link which talks of a similar issue that got resolved by switching to Felix version 2.0.2. Maybe you could try that?
It's hard to be definitive without looking at the JamVM source code, but the stacktrace tells me that inside getZoneStrings there is an attempt to load a class or other file via the classloader (hence the call to ClassLoader and URLClassLoader three layers down the stack).
That attempt at classloading is not finding the address a URL that is in the classpath. That could be because you have a problem later on in your classpath and since it didn't find the file where you are putting your classes it went looking in the next place, which had an UnresolvedAddressException (by the way, that seems like an odd violation of the spec, the classloader should throw its checked exception. Here it seems that GNU classpath is letting a runtime exception leak out which should instead be converted into an exception indicating that the class cannot be found), or it could just be that that is what it does when it can't find a resource.
As for what class is not being found, it seems to be one of the ServiceProviders configured, perhaps in GNU Classpath:
at gnu.classpath.ServiceFactory.lookupProviders(Servi ceFactory.java:286)
The above is the core of the problem. It is looking up a provider, and attempted to get a resource from the classpath that likely doesn't exist.
It is impossible to say what exactly it is looking for without examining the source code. Fortunately you seem to be using all open source stuff, so it should be fairly easy to find.
Thanks JRL, the solution posted in the link you suggested me solved the problem!
I couldn't expect in such a bug of felix even because I thought I had already used Date and Calendar classes on the same platform and in the same conditions!
Just sum up of solution:
download newer version of felix (from at least 2.0.2) - from http://felix.apache.org/site/downloads.cgi get the .jar named Main (i.e. the bundle for the OSGi framework)
save it in the bin/ directory where your current felix.jar resides
rename felix.jar as felix.jar_old (after shutting down the OSGi FX if it's running!)
rename the newer version of felix (ex. org.apache.felix.main-2.0.3.jar) as felix.jar
restart the OSGi framework with your app
Hope this helps to someone else!
Bye,
Andrea
(Sorry for the second username...I register quite long time ago but I forgot about the google identification! :-) )
Related
This is my first post on stackoverflow, please be indulgent.
Within my project, I use the library commons-digester-1.8.
Following a need, I now use the library gwt-dev-2.3.0.
When launching the application I get this error :
Exception caught while initializing context java.lang.NoSuchMethodError: org/apache/commons/digester/xmlrules/DigesterLoader.createDigester(Lorg/xml/sax/InputSource;)Lorg/apache/commons/digester/Digester;
at fr.cnasea.commons.webfwk.util.config.lecture.XMLDigesterReader.getConfig(XMLDigesterReader.java:157)
at fr.cnasea.commons.webfwk.util.config.CnaseaAppConfigurator.configure(CnaseaAppConfigurator.java:76)
at fr.cnasea.osiris.commons.gwt.server.Config.contextInitialized(Config.java:47)
It turns out that the two libraries have the same class in the same package with the same method:
Same class
Since the use of gwt-dev, it is the method of this library which is called.
I tried to use newer versions of gwt-dev but the environment makes it not possible
How can I fix it?
Thanks for your help :)
(From my answer to your same question on the github project)
The gwt-dev.jar should not be on your server classpath - it is only used to compile your application. The same is true for gwt-user.jar. Only gwt-servlet.jar (and possibly requestfactory-server.jar) should end up on your server classpath, the others are intended only to be present when compiling, either to do the work of compiling, or to provide the compiler the classes you need.
I am working on moving code from R2007a to R2013a. I am getting a java.lang.NoClassDefFoundError during my run in R2013a which does not appear in R2007a. It occurs when I call.
feval('get',fname,jevent);
Where fname is a product.ProxyField object for an Object Filter and jevent is a product.format.java.internal.JavaEvent.
The class is in a jar file on the path and is being accessed by another class in the same jar file. The stack trace does not leave the realm of the product if that helps.
I do not have access to the original code for the jar file. I do have access to code derived from that original code and both classes are in the same package. I'm guessing this has something to do with differences in the java version but I'm not sure what to do since I don't have the original code to recompile.
Unfortunately I can't provide actual source or full detail but a google search only yielded results for MATLAB startup issues. Any thoughts?
Seems like the difference between R2007a and R2013a is that the first uses 1.5 jre and second uses 1.6 jre. It would be easier to help you if you provided the stack trace showing the exception. Sometimes classes get moved around in between jvm versions, so having the actual missing classes would help in determining if the missing class is a class that was just moved around to a different package. You could take the missing class, google it adding the same exception message as you put above and seeing who else ran into similar issues.
Spring framework throws
Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
at org.apache.commons.logging.impl.SLF4JLocationAwareLog.info(SLF4JLocationAwareLog.java:159)
at org.springframework.context.support.AbstractApplicationContext.prepareRefresh(AbstractApplicationContext.java:454)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:392)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93)
what's the reason?
The reason is wrong version of library added (version conflict).
Check for the version of slf4j 's javadoc and try to figure out ,this method exist with which version ?
If you are running OSX you might find this is because the following files are included as java extensions:
/Library/Java/Extensions/slf4j-api-1.5.8.jar
/Library/Java/Extensions/slf4j-log4j12-1.5.8.jar
These are loaded by the extension classloader, before your application classloader, so these will be resolved first.
I have no idea why these are there or when they were added but i've only seen this on OSX and in the last year, which might imply they were introduced in java 6.
You can remove\move the files to workaround the problem, but there might be some applications which depend on them.
You might be having a class twice in your classpath.
Check the classpath for the occurrences.
I have a Java (6) application which uses Hibernate (V3.3.2) to read data from HSQLDB, which i build and debug/run with Eclipse (V3.5.1), and it works fine.
I then created a GWT (V1.7) Servlet web app, copied my hibernate classes into it, and added the same User Libraries dependencies. However when i run the servlet and try to access a URL which invokes my code i get this:
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:152)
at xxx.daoimpl.DAOSession.initialise(DAOSession.java:40)
where DAOSession.java:40 is :
AnnotationConfiguration config = new AnnotationConfiguration ();
Googling for this error suggests i am missing slf4j-api.jar from the classpath, however if i look at the command line for the Debug properties i can see this jar there:
C:\java\jsedk_6\jre\bin\javaw.exe
-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:54541
-Xmx512m -Dfile.encoding=Cp1252
-classpath
D:\dev\workspace\xxx\src;
D:\dev\workspace\xxx\resources;
D:\dev\workspace\xxx\war\WEB-INF\classes;
C:\java\eclipse\plugins\com.google.gwt.eclipse.sdkbundle.win32_1.7.1.v200909221731\gwt-windows-1.7.1\gwt-user.jar;
C:\java\eclipse\plugins\com.google.gwt.eclipse.sdkbundle.win32_1.7.1.v200909221731\gwt-windows-1.7.1\gwt-dev-windows.jar;
C:\java\hibernate-annotations-3.4.0.GA\hibernate-annotations.jar;
C:\java\hibernate-annotations-3.4.0.GA\lib\ejb3-persistence.jar;
C:\java\hibernate-annotations-3.4.0.GA\lib\hibernate-commons-annotations.jar;
C:\java\hibernate-distribution-3.3.2.GA\hibernate3.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\antlr-2.7.6.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\commons-collections-3.1.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\dom4j-1.6.1.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\javassist-3.9.0.GA.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\jta-1.1.jar;
C:\java\hibernate-validator-4.0.1.GA\hibernate-validator-4.0.1.GA.jar;
C:\java\hibernate-validator-4.0.1.GA\lib\validation-api-1.0.0.GA.jar;
C:\java\hibernate-validator-4.0.1.GA\lib\log4j-1.2.14.jar;
C:\java\hsqldb\lib\hsqldb.jar;
C:\java\restlet-jse-2.0m5\lib\org.restlet.jar;
C:\java\restlet-jee-2.0m5\lib\org.restlet.ext.servlet.jar;
C:\java\restlet-jse-2.0m5\lib\org.restlet.ext.xml.jar;
C:\java\slf4j-1.5.8\slf4j-api-1.5.8.jar;
C:\java\slf4j-1.5.8\slf4j-log4j12-1.5.8.jar
com.google.gwt.dev.HostedMode
...
If i open the jar i can see the LoggerFactory class in there.
Any idea why it isn't being found by the class loader?
Edit 1: If try to access org.slf4j.LoggerFactory from my code, Eclipse compiles it ok, but i get the same error at runtime.
Edit 2: If i add a Test class with a main which calls the same code and run it, it works. So this classpath problem seems specific to the Servlet.
thanks,
jon
It seems that copying the two slf4j jars to the war/WEB-INF/lib sub-project/dir fixed the problem. I'm not really sure why i should need to do this for these two jars and not for all the other Hibernate, Restlet etc jars that the project also uses, though i suppose for consistency i will do that anyway - i guess it will make deployment easier as well.
If someone can provide some sort of explanation as to why this worked and why exactly i need to do it i will select it as the "correct" answer, otherwise i'll select this one.
Can you please reconfirm that you have at least two slf4j.jar files in the classpath, the slf4j-api.jar and exactly one implementation, such as slf4j-jdk14.jar?
You must not have multiple sflj4-implementations in the classpath.
You have a runtime dependency issue so everything compiles fine but the dependency is in your jars. You need to visit the Hibernate site and look at the compatibility matrix and make sure you are matched up correctly then check the dependencies for annotations and core. You log4J jars look fine so it's definitely some quirk.
If it works in Eclipse then logically it's definitely some diff between the 2 runtimes (eclipse and non-eclipse), if the matrix checks out fine then see if you can factor out the commonalities in the 2 then work out the differences -- your answer should be in there.
I had a similar issue except I was using Tomcat and the NoClassDefFound error was on the juli logger. I fixed it by removing the Tomcat dependencies from my classpath when running in hosted mode because hosted mode embeds a Tomcat server that was conflicting. So I would see what happens if you remove some or all of the restlet jars from your classpath to see if they conflict.
I was hoping someone could help me out with a problem I'm having using the java search function in Eclipse on a particular project.
When using the java search on one particular project, I get an error message saying Class file name must end with .class (see stack trace below). This does not seem to be happening on all projects, just one particular one, so perhaps there's something I should try to get rebuilt?
I have already tried Project -> Clean... and Closing Eclipse, deleting all the built class files and restarting Eclipse to no avail.
The only reference I've been able to find on Google for the problem is at http://www.crazysquirrel.com/computing/java/eclipse/error-during-java-search.jspx, but unfortunately his solution (closing, deleting class files, restarting) did not work for me.
If anyone can suggest something to try, or there's any more info I can gather which might help track it's down, I'd greatly appreciate the pointers.
Version: 3.4.0
Build id: I20080617-2000
Also just found this thread - http://www.myeclipseide.com/PNphpBB2-viewtopic-t-20067.html - which indicates the same problem may occur when the project name contains a period. Unfortunately, that's not the case in my setup, so I'm still stuck.
Caused by: java.lang.IllegalArgumentException: Class file name must end with .class
at org.eclipse.jdt.internal.core.PackageFragment.getClassFile(PackageFragment.java:182)
at org.eclipse.jdt.internal.core.util.HandleFactory.createOpenable(HandleFactory.java:109)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1177)
at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:223)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:506)
at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:551)
at org.eclipse.jdt.internal.corext.refactoring.RefactoringSearchEngine.internalSearch(RefactoringSearchEngine.java:142)
at org.eclipse.jdt.internal.corext.refactoring.RefactoringSearchEngine.search(RefactoringSearchEngine.java:129)
at org.eclipse.jdt.internal.corext.refactoring.rename.RenameTypeProcessor.initializeReferences(RenameTypeProcessor.java:594)
at org.eclipse.jdt.internal.corext.refactoring.rename.RenameTypeProcessor.doCheckFinalConditions(RenameTypeProcessor.java:522)
at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:45)
at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:225)
at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:160)
at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper$Operation.run(RefactoringExecutionHelper.java:77)
at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4650)
at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:92)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Thanks McDowell, closing and opening the project seems to have fixed it (at least for now).
Comment #9 to bug 269820 explains how to delete the search index, which appears to be the solution to a corrupt index whose symptoms are the dreaded
An internal error occurred during: "Items filtering".
Class file name must end with .class
message box.
How to delete the search index:
Close Eclipse
Delete <workspace>/.metadata/.plugins/org.eclipse.jdt.core/*.index
Delete <workspace>/.metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt
Start Eclipse again
Two more general-purpose mechanisms for fixing some of Eclipse's idiosyncrasies:
Close and open the project
Delete the project (but not from disk!) and reimport it as an existing project
Failing that, bugs.eclipse.org might provide the answer.
If the workspace is caching something broken, you may be able to delete it by poking around in workspace/.metadata/.plugins. Most of that stuff is fairly transient (though backup and watch for deleted preferences).
Got this error to the other day. Tried deleting the all .class-files and resources from my output folder manually. Didn't work. Restarted my computer (WinXP). Didn't work. Closed my project in Eclipse and opened it again. Worked!!! Hopes this solves someones problem out there. The search facilities and truly essential to Eclipse.
I also encountered this issue recently, the below scenario worked for me.
Close Eclipse
Delete <workspace>/.metadata/.plugins/org.eclipse.jdt.core/*.index
Delete <workspace>/.metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt
Start Eclipse again
Closing the projects didn't do the trick for me. I started eclipse with the -clean flag and that worked for some reason.
Just
Close project
Clear manually output folder(s)
Open project
(Eclipse 3.5 SR2, Build id: 20100218-1602)