This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When using: URL url = getClass().getResource("/org/yourorghere/module1/JarURLTestAction.class"); in a module suite project with Netbeans 6.1beta the url contains: nbjcl:file:/home/mgoe/NetBeansProjects/suite9/build/cluster/modules/org-yourorghere-module1.jar!/org/yourorghere/module1/JarURLTestAction.class This URL cannot be used by third party libraries because the protocol nbjcl is unknown. The same code worked fine in NB 6.0. So this is a regression which has to be fixed as soon as possible. Best regards, Martin Goettlicher
Created attachment 58149 [details] Module suite project showing the issue.
In order to reproduce the problem please use the module suite project attached and select File->JarFileURL Test and have a look at the output.
The new protocol implements an improved module cache and loading system. URL seems to work for me: System.out.println(url.openConnection().getContentLength()); => 2275 If you want a jar-protocol URL for some other purpose, you can use e.g. System.out.println(new URL(FileUtil.getArchiveRoot(getClass().getProtectionDomain().getCodeSource().getLocation()), "org/yourorghere/module1/JarURLTestAction.class")); or simply s/^nbjcl/jar/ what getClass() provides.
It's no so easy. There are a lot of third party libraries out there which use getClass().getResource() to read resource files etc. All these libraries will no longer work because they don't do the magic jglick described. That means you cannot use third party libraries any more. I find it very annoying that netbeans reinvents the wheel in every place. Coding practices which were valid long before netbeans was invented don't no longer work from one netbeans version to the other. You cannot break interfaces specified in the jdk. From the URL class javadoc: "Protocol handlers for the following protocols are guaranteed to exist on the search path :- http, https, ftp, file, and jar" So there is no guarantee for a nbjcl protocol handler. And therefore this protocol is useless since no third party library will ever support it. Please fix this regression from netbeans 6.0 and make getClass().getResource() return a jar file URL again. Best regards, Martin Goettlicher
You only need to do something special if you specifically want a jar-protocol URL. The nbjcl-protocol URL can be opened and used as it is. The Java platform does not specify what kind of URL will be returned for Class.getResource. That is entirely dependent on the ClassLoader implementation. The enumeration of "supported" protocols means simply that an application which does not register any URL stream handlers of its own will automatically be able to create and open URLs using those protocols. The NB platform defines a new handler and uses it. If there is a concrete problem which can be observed due to this change, i.e. a minimal module or suite working as expected in 6.0 and not in 6.1, then please attach for inspection.
Code such as (see also code example in javadoc of class JarURLConnection): URL url = getClass.getResource("Some Resource"); JarURLConnection jarConnection = (JarURLConnection)url.openConnection(); will no longer work since the object returned by url.openConnection() cannot be cast to a JarURLConnection. From the javadoc of URL.openConnection(): "Returns a URLConnection object that represents a connection to the remote object referred to by the URL. A new connection is opened every time by calling the openConnection method of the protocol handler for this URL. If for the URL's protocol (such as HTTP or JAR), there exists a public, specialized URLConnection subclass belonging to one of the following packages or one of their subpackages: java.lang, java.io, java.util, java.net, the connection returned will be of that subclass. For example, for HTTP an HttpURLConnection will be returned, and for JAR a JarURLConnection will be returned."
The question still remains why would you (or the library) cast specifically to the JarURLConnection? Why isn't URLConnection good enough for you [*]? If your classes were laid out plain in a folder (very legal and JDK-well-handled case), you'll see the same problem, casting FileURLConnection to JarURLConnection, for examle. *) Well, I can imagine a construct trying to find its own class to locate the jar and reference relatively-positioned files from installation. But even in this case, the NetBeans way is to use InstalledFilesLocator, and the common (JDK) way is to follow the path of getClass().getProtectionDomain().getCodeSource().getLocation(), which will work OK even under NetBeans.
Right, I am still looking for a concrete example of a library which inherently requires a jar-protocol URL. And does this library still work e.g. from a (JDK 6+) Java Web Start app where the URLs will be http-protocol? Or with an unpacked dir of classes where the URLs will be file-protocol, as Petr mentioned? Or in ClassWorlds which has its own specialized loading scheme?
Sorry for not responding promptly. pnejedly had the correct assumption. Each of our modules can have its own icons (which are svg files embedded in the jar file of the module). Inspired by the code example in the javadoc of the class JarURLConnection I used JarURLConnection.getJarFileURL() to get the URL of my svg file because the transcoder of the batik toolkit allows to transcode a svg file from an URL/URI. This was what failed because the batik transcoder didn't know how to handle the nbjcl protocol. I now have implemented a solution which uses an InputStream for the transcoder input so I no longer need the URL. What annoyed me was the fact that code which was running for years with netbeans 5.0, 5.5, 5.5.1 and 6.0 stopped working after I switched to netbeans 6.1beta (which I thought was just an update release fixing some bugs). The accompanying documentation also didn't mention this change.
Good point, I noted the change in Modules API: #f2c147247cc2 If we find a reasonably straightforward way to use jar protocol for module resources, we would do that. It was considered but seemed rather more complicated, as we would need to replace the JRE's protocol handler, delegating to it for JARs which are not in fact modules.
*** Issue 130618 has been marked as a duplicate of this issue. ***
any updates on nbjcl issue. i am stuck on this for a while and cannot seem to progress. any quick fix would really help. thanks sri Caused by: java.io.FileNotFoundException: nbjcl:file:/C:/Temp2/MySuite/build/cluster/modules/moduleA.jar!/ at org.netbeans.JarClassLoader$ResURLConnection.connect(JarClassLoader.java:844) at org.netbeans.JarClassLoader$ResURLConnection.getInputStream(JarClassLoader.java:869) at java.net.URL.openStream(URL.java:1009) at org.apache.openjpa.lib.util.J2DoPrivHelper$39.run(J2DoPrivHelper.java:825) at java.security.AccessController.doPrivileged(Native Method) at org.apache.openjpa.lib.meta.URLMetaDataIterator.getInputStream(URLMetaDataIterator.java:67) at org.apache.openjpa.lib.meta.ClassArgParser.parseTypeNames(ClassArgParser.java:243)
No changes planned for 6.1. sri: I am not sure what your stack trace means, but if you can find a minimal self-contained test case demonstrating the problem, please file a separate bug report for evaluation.
I can propose some untested patches. Probably too late for 6.1, TBD.
Created attachment 59712 [details] Simple patch to use jar URLs for certain JARs only
Looks good for me. I will try it out and keep you posted. Thanks for your effort.
Created attachment 59717 [details] Patch using option #1: produces jar-protocol URLs, handling NB's own with the special cache, delegating others
How and where to find these updates. I tried to pull sources last night using hg pull -u and also did hg update. But I cudn't find these changes. I would greatly appreciate if I can pull these changes. I have 'main' as cloned repo. I tried to manually merge these changes but cudn't make NB start. thanks sri
The potential fixes are available as patches only, for purposes of evaluation and discussion; they are not in the repo.
jesse, thanks for the update. i mean to say these changes must be somewhere in the system not necessarily the main repo( if i can atleast browse to these changed files). i want to have the these files wherever they are located so that i can test these changes. is this possible? thanks sri
Again: the changes are not in any repository. They are available as patches only.
Created attachment 60247 [details] Issues after making changes
Created attachment 60248 [details] Issues after making changes
i've tested again today and found the following issues. earlier i forgot to change the META-INF/services value for startup. the changes have solve the issue. im able to get what i want. thanks to all the folks who invested so much time. i really appreciate your help. however, i do get some errors during startup ( 1 and 2) and while trying to build the project for the first time ( 3 thru 6) in the attachments. it might be possible that i might be missing something. please correct me. thanks and thanks once again sri
*** Issue 127268 has been marked as a duplicate of this issue. ***
x
I have a fix that seems to work, using option #1: go back to using "jar" protocol rather than "nbjcl", but with a special protocol handler which loads NB module resources from the binary cache. It is slightly different from the patch I last attached; I found I needed to override parseURL in the handler, to deal with javawebstart and websvc.* modules which use url="/..../something" in their layers (a questionable practice but probably should be permitted). I did not find any problems with Java SE library definitions such as sri seemed to be having. Review would be appreciated of course. #7ccf89a50f5f in core-main. Could potentially be backported to a 6.1 update release, though it is a somewhat dangerous fix so I don't really recommend it; better to let it mature in dev builds.
Additional #fbc63451ecd9 in core-main just fixes JarClassLoaderTest.
Additional fix for issue #134424 in 7d33b9d2ed38.
#3391c5e1cc92 removes the notice of incompatibility from API changes for 6.5, so it should only appear in 6.1 Javadoc.
Integrated into 'main-golden', available in NB_Trunk_Production #206 build Changeset: http://hg.netbeans.org/main/rev/3391c5e1cc92 User: Jesse Glick <jglick@netbeans.org> Log: Removing notice of incompatibility for issue #129772 (nbjcl protocol) since we are back to jar protocol.
This issue had *2 votes* before move to platform component