Java - UnresolvedAddressException due to lack of timezone info?

Question

Hi to everyone, 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

Answer 1

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.

Answer 2

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?

Answer 3

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! :-) )