Bug 122930

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.