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.
Summary: | Switch to Jersey version 1.0 | ||
---|---|---|---|
Product: | webservices | Reporter: | Peter Liu <petertliu> |
Component: | REST | Assignee: | Peter Liu <petertliu> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dlipin, gtzabari, japod, jungi, mzlamal |
Priority: | P4 | Keywords: | PLAN |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: | iff -u -N bundled.jersey.txt orig.jersey.txt |
Description
Peter Liu
2007-11-28 01:53:15 UTC
moving opened issues where TM != dev to TM=TBD I am switching this from a FEATURE to a DEFECT because Netbeans 6.5 bundles libraries it claims are JAX-RS 1.0 and Jersey 1.0 but they are older versions (maybe betas). We should upgrade to 1.0 final before Netbeans 6.5 is released because these contain API changes! Which IDE build do you use? Can you give us any prove that what's in the IDE 6.5 RC1 is not Jersey 1.0 FCS? from the jersey.jar/META-INF/manifest.mf: Build-Id: 1.0 10/13/2008 01:33 PM Bnd-LastModified: 1223897606802 Implementation-Vendor-Id: com.sun.jersey Implementation-Title: jersey-bundle Bundle-SymbolicName: jersey-bundle-1.0 Implementation-Version: 1.0 from the jsr311-api.jar/META-INF/manifest.mf: Build-Id: 10/07/2008 12:26 PM Bnd-LastModified: 1223375202410 Specification-Version: 1.0 Bundle-Version: 1.0 Bundle-Name: jsr311-api I got an exception in Jersey yesterday but the line numbers didn't match the source code for 1.0 (which I downloaded off their site). So I downloaded their 1.0 JARs and suddenly it lined up. You should be able to extract both JARs and compare the class files. You should find some differences. This is where we got the jersey jar file: http://download.java.net/maven/2/com/sun/jersey/jersey-bundle/1.0/jersey-bundle-1.0.jar Also note that we are not planning to update NB 6.1 to jersey 1.0. The only way to get support for jersey 1.0 is to upgrade to NetBeans 6.5. If you download this file again and compare it against the version you ship with Netbeans 6.5 you will notice they differ. I suspect someone updated this JAR file instead of putting out a new version. at least the name of file/class where you see the difference would really help us to investigate this... I'm also attaching the diff between jersey-bundle-1.0.jar from maven repo and jersey.jar in 6.5 RC1 I got using following commands: jar tvf jersey.jar > bundled.jersey.txt jar tvf jersey-bundle-1.0.jar > orig.jersey.txt diff -u -N bundled.jersey.txt orig.jersey.txt > iz122930.diff as can be seen from the diff for some files timestamp is the same but size is different - don't really know why - Peter, Jakub do you have any idea? forgot to cc Jakub... Created attachment 72565 [details]
iff -u -N bundled.jersey.txt orig.jersey.txt
I tried doing the diff on my mac and there is no difference. Now I am wondering if the Mac does something funny to the binary when I download it. Does anyone know? gtzabari: could you please try again against sources obtained the following way: svn co https://jersey.dev.java.net/svn/jersey/tags/jersey-1.0/jersey jersey-1.0 then if you still see differences, could you please let us know what source files differs at what lines. The SVN version of jersey-core is missing the following files in com.sun.jersey.impl: api.properties ApiMessages.java impl.properties ImplMessages.java spi.properties SpiMessages.java The SVN version of jersey-server is missing com.sun.jersey.impl.build.properties and com.sun.research.* Aside from that they seem to be identical. NetBeans the uses jersey-bundle and renames it to jersey.jar: http://download.java.net/maven/2/com/sun/jersey/jersey-bundle/1.0/jersey-bundle-1.0.jar I am convinced that this has something to with the ant zip task on Mac. I just recently switched to a Mac and I used the ant zip task to create a bundle of all the necessary jar files for jersey including the jersey-bundle. However, if I were to unzip the zip file on my Mac, I get all the files with their original file sizes back. However, I just installed the RC2 build on my mac and did a comparison, all the file sizes are different between my own build and the RC2 build which is not built on a Mac. Lukas, if you have both a mac and a windows or linux machine, could you verify that this is indeed the case? cc'ing Michal (RE), maybe he can shed some light into this. The unzipped content is always the same and doesn't depend on platform. You are unzipping jars and if you are still able to unzip the produced jar then be sure that that unzipped jar is OK. I'd say that either the jars in zip are wrong or jersey developers changed they distro after you've downloaded it. Lukas, Michal, if you do a build on a mac, you will notice that the jersey jar files are different from the ones in the RC2 build. I believe the jersey jar files in the Mac build truly reflect the original jersey jar files. Somehow, they are different on other platforms. Peter, I've tried to build it on my Mac and the jarsey.jar is exactly the same as is in RC2 build: michal@trpaslik:~/work/mercurial/release65/nbbuild/netbeans/enterprise5/modules/ext/rest$ md5 * MD5 (asm-3.1.jar) = 4fbe0fd975ecc71480846ce272b483b0 MD5 (grizzly-servlet-webserver-1.7.3.2.jar) = 0efd8600125b1d15e1ab2f7633d33d67 MD5 (http.jar) = 8a59b08aac28cf38a0bacf40a63ad2af MD5 (jdom-1.0.jar) = 0b8f97de82fc9529b1028a77125ce4f8 MD5 (jersey-spring.jar) = 4c87c45d99e61df90ed784e01165aaab MD5 (jersey.jar) = cfe3714b87940fbaf958e44c9233243a MD5 (jettison-1.0-RC1.jar) = 48003bfd6f5ab293a515299fdced487a MD5 (jsr311-api.jar) = ae64e2f19820b689d1c659a47f7bb9b6 MD5 (rome-0.9.jar) = 7abe6d06c4c395bc3ac8791592f78670 MD5 (wadl2java.jar) = 49b0b8547893426451884919a732b6c3 michal@trpaslik:~/work/mercurial/release65/nbbuild/netbeans/enterprise5/modules/ext/rest$ cd ~/work/netbeans/enterprise5/modules/ext/rest/ michal@trpaslik:~/work/netbeans/enterprise5/modules/ext/rest$ md5 * MD5 (asm-3.1.jar) = 4fbe0fd975ecc71480846ce272b483b0 MD5 (grizzly-servlet-webserver-1.7.3.2.jar) = 0efd8600125b1d15e1ab2f7633d33d67 MD5 (http.jar) = 8a59b08aac28cf38a0bacf40a63ad2af MD5 (jdom-1.0.jar) = 0b8f97de82fc9529b1028a77125ce4f8 MD5 (jersey-spring.jar) = 4c87c45d99e61df90ed784e01165aaab MD5 (jersey.jar) = cfe3714b87940fbaf958e44c9233243a MD5 (jettison-1.0-RC1.jar) = 48003bfd6f5ab293a515299fdced487a MD5 (jsr311-api.jar) = ae64e2f19820b689d1c659a47f7bb9b6 MD5 (rome-0.9.jar) = 7abe6d06c4c395bc3ac8791592f78670 MD5 (wadl2java.jar) = 49b0b8547893426451884919a732b6c3 michal@trpaslik:~/work/netbeans/enterprise5/modules/ext/rest$ More, the md5 of all the files from enterprise5/ext/rest dir are OK. As I wrote already zip works on all platforms the same! My build on the Mac has exactly the same MD5s as your build: dhcp-umpk16-80-139:rest peterliu$ pwd /Users/peterliu/dev/hg2/release65/nbbuild/netbeans/enterprise5/modules/ext/rest dhcp-umpk16-80-139:rest peterliu$ md5 * MD5 (asm-3.1.jar) = 4fbe0fd975ecc71480846ce272b483b0 MD5 (grizzly-servlet-webserver-1.7.3.2.jar) = 0efd8600125b1d15e1ab2f7633d33d67 MD5 (http.jar) = 8a59b08aac28cf38a0bacf40a63ad2af MD5 (jdom-1.0.jar) = 0b8f97de82fc9529b1028a77125ce4f8 MD5 (jersey-spring.jar) = 4c87c45d99e61df90ed784e01165aaab MD5 (jersey.jar) = cfe3714b87940fbaf958e44c9233243a MD5 (jettison-1.0-RC1.jar) = 48003bfd6f5ab293a515299fdced487a MD5 (jsr311-api.jar) = ae64e2f19820b689d1c659a47f7bb9b6 MD5 (rome-0.9.jar) = 7abe6d06c4c395bc3ac8791592f78670 MD5 (wadl2java.jar) = 49b0b8547893426451884919a732b6c3 However, the MD5s for my RC2 installation are completely different: dhcp-umpk16-80-129:rest peterliu$ pwd /applications/netbeans/NetBeans 6.5 RC2.app/Contents/resources/netbeans/enterprise5/modules/ext/rest dhcp-umpk16-80-129:rest peterliu$ md5 * MD5 (asm-3.1.jar) = a0c3315f1204e0068748ea0c7ca1ca2d MD5 (grizzly-servlet-webserver-1.7.3.2.jar) = 4ba84c40130acd937c17294d23d5a711 MD5 (http.jar) = 074e6f827d1be86bcce8261d26144db4 MD5 (jdom-1.0.jar) = bb7f8f42be60a0cd074193e3d2c48973 MD5 (jersey-spring.jar) = 1fd92c8ba73afa054f5593c6333823d3 MD5 (jersey.jar) = 2984eab3f97a94034b73c0a43c65789f MD5 (jettison-1.0-RC1.jar) = 4318410144f139c31ec14fda93af6877 MD5 (jsr311-api.jar) = baa99cb60fa873cf47df4e64d4831665 MD5 (rome-0.9.jar) = a9fb10357e73c3d506da910001c01d71 MD5 (wadl2java.jar) = a0822dbe670b4e8ef83a5b835428804b This is getting really strange. I used netbeans RC2 zip file, so only option now is that installer's pack200 changed the jar and unpack200 didn't put it back to same state as it was before. Dima, could you please comment? We use pack200->unpack200 operation (pack200 during the build and unpack200 during the installation) in installer for all not signed jar files to reduce the download size of the bundles. Right, this operation can (and in most cases do) change the jar file size and md5 sum. Functionality of the jar file should not be affected. Dima, this shouldn't cause the line numbers not to match up with the source, right? If we are speaking about the pack200 specification (JSR-200), then information about line numbers should be preserved (LineNumberTable) http://doc.javanb.com/javasdk-docs-6-0-en/technotes/guides/pack200/pack-spec.html If we are speaking about implementations then I can`t say that for sure. The first result for googling "pack200 LineNumberTable" gives the link to some pack200 implementation (in Apache Harmony) that contained an issue in that area for some time in the past https://issues.apache.org/jira/browse/HARMONY-5570 I personally not aware of any such issues in Sun`s (and Apple`s) pack200 implementations (maybe Bugster knows more:). Does that issue really exist (i.e. line numbers change) or was it just a theoretical question? :) Well, we are trying to figure out the root cause of the problem reported by the user (see the 5th comments from the top) and that's when we noticed the differences in the file sizes. gtzabari, what is the exception? could you please provide the stacktrace and steps to reproduce? what is the JDK? what is the OS? It is hard to tell fortunes by coffee grounds. If it is not reproducible in the ZIP file [1] and reproducible with installers [2] (!in case of using the same JDK for NB!), then likely something wrong with packing or unpacking. If it is reproducible in ZIP then, definitely, the wrong Jersey jar is bundled but is is likely not the case due to sandos comment on Oct 27 07:59:52 +0000 2008. [1] http://download.netbeans.org/netbeans/6.5/rc/zip/netbeans-6.5rc2-200810270001-ml.zip [2 Installers: http://download.netbeans.org/netbeans/6.5/rc/bundles/netbeans-6.5rc2-ml-windows.exe http://download.netbeans.org/netbeans/6.5/rc/bundles/netbeans-6.5rc2-ml-linux.sh http://download.netbeans.org/netbeans/6.5/rc/bundles/netbeans-6.5rc2-ml-macosx.dmg http://download.netbeans.org/netbeans/6.5/rc/bundles/netbeans-6.5rc2-ml-solaris-sparc.sh http://download.netbeans.org/netbeans/6.5/rc/bundles/netbeans-6.5rc2-ml-solaris-x86.sh Dmitry and the other not less important question is under what JDK was installation performed. On non-Mac platforms it can be done by looking at ~/.nbi/log directory at the corresponding log file (likely the latest). The information about the Java used is located almost at the beginning of the file. On Mac just the output of "/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/bin/java -version" makes sense. Here is the original message I posted when I ran across the exception: http://n2.nabble.com/NPE-at-com.sun.jersey.spi.container.ContainerRequest-tc1365881.html JDK: 1.6.0 update 10, same for installation OS: Windows Vista 64-bit You will get this exception if you construct the Jersey servlet and invoke service() on it without first invoking init() -- in other words, if you violate the servlet API. I was using the warp-servlet library and misconfigured it in a way that caused this behavior by mistake. I can put try putting together a testcase for you if you wish... PS: http://n2.nabble.com/UriInfo-mishandling-port-numbers-tc1508438.html might be a related bug. I will try reproducing this under Jersey 1.0 directly off their website. If the problem goes away then this is an easier way to prove that Netbeans is using the wrong version. Dear god... I can't believe I wasted so much time on this issue! @!#%%$# It turns out that my project has a local library folder which I imported JAX-RS 1.0 and Jersey 1.0 into. Netbeans then updated those libraries without changing the name. As a result I was under the impression I was using Jersey 1.0 when in fact I was not. This, in turn, lead to all the issues I've reported. I've verified this using http://n2.nabble.com/UriInfo-mishandling-port-numbers-tc1508438.html I can reproduce the problem using my library versions. If I then delete the libraries and re-import them from Netbeans the problem goes away. A file comparison shows the files are different. Lesson of the day: *please* use a different library name in the future. If you're bundling Jersey 1.x snapshot please describe it as such instead of "1.0". Alternatively (probably even better): Any library the user imports from Netbeans should be flagged for syncing. If the version in Netbeans does not match the imported version then Netbeans should report a warning (similar to when libraries are missing). This way, if Netbeans doesn't know the imported library it'll silently ignore it and assume it's the correct version. If it knows the imported library it'll verify its integrity. With your permission I'd like to modify this issue into that RFE. Okay, I've filed a separate enhancement request as issue 153470. Feel free to close this issue as fixed. I apologize for the inconvenience. I believe you were using a pre-beta trunk build that contained a version of the 1.0 snapshot. At the time, we did all the necessary changes for the upgrade upfront and were simply updating the binaries as they become available for testing purpose. We didn't anticipate this would cause confusions for users. We will keep this mind in the future. No worries. It gave me incentive to file issue 153470 which I had wanted to file for a while now ;) Hopefully you won't have to worry about making these kinds of changes in the future. |