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.

Bug 208706

Summary: REST sample cannot be deployed to GlassFish 3.1.2.
Product: javaee Reporter: Jiri Skrivanek <jskrivanek>
Component: SamplesAssignee: Martin Janicek <mjanicek>
Status: VERIFIED FIXED    
Severity: normal CC: ads, mmatula, mmirilovic, pjiricka, TomasKraus, vkraemer, vriha
Priority: P1    
Version: 7.1.1   
Hardware: PC   
OS: Windows XP   
Issue Type: DEFECT Exception Reporter:
Attachments: Server log.
CustomeDBSpring project diff.
Patch for release71_fixes branch.

Description Jiri Skrivanek 2012-02-21 15:01:57 UTC
Created attachment 115986 [details]
Server log.

It is not possible to deploy REST sample hello world to GlassFish 3.1.2. To reproduce:

- install NetBeans 7.1.1 from zip
- register GlassFish 3.1.2 server
- open new project wizard
- choose "Samples|Java Web Services|REST: Hello World"
- finish wizard
- run project but it fails to deploy it:

deploy?DEFAULT=D:\Development\builds\NB711\nbUserdir-20120221154710\HelloWorld\HelloWorld\build\web&name=HelloWorld&contextroot=/HelloWorld&force=true failed on GlassFish Server 3+ 
 Error occurred during deployment: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: com.sun.jersey.spi.inject.Errors$ErrorMessagesException. Please see server.log for more details.
D:\Development\builds\NB711\nbUserdir-20120221154710\HelloWorld\HelloWorld\nbproject\build-impl.xml:727: The module has not been deployed.
See the server log for details.

Product Version: NetBeans IDE 7.1.1 RC1 (Build 201202141941)
Java: 1.7.0_03; Java HotSpot(TM) Client VM 22.1-b02
System: Windows XP version 5.1 running on x86; Cp1250; en_US (nb)
Comment 1 Jiri Skrivanek 2012-02-21 15:05:34 UTC
It fails also for other REST samples from this category.
Comment 2 Marian Mirilovic 2012-02-21 21:50:14 UTC
Stopper for 7.1.1 ... please evaluate ASAP. Thanks in advance.
Comment 3 Petr Jiricka 2012-02-22 08:30:53 UTC
Cc'ing also Denis - Denis and Martin, can you please investigate ASAP? Thanks.
Comment 4 Denis Anisimov 2012-02-22 09:25:54 UTC
That's the interference Jersey libraries problem I suppose.
I believe this is the runtime problem and should be solved on GF side :
web project has Jersey 1.8 packaged libraries.
Probably this is the reason why there is a deployment error.
GF should allow user to have some Jersey specific version packaged with the application.

The problem could be solved by removing NB bundled Jersey library from the 
project classpath.
That will work for J2EE servers supported JEE6.
Comment 5 TomasKraus 2012-02-22 11:30:48 UTC
Verified with trunk builds (NB 7.2, GF 4) and see the same problem.
Comment 6 Denis Anisimov 2012-02-22 13:53:29 UTC
This is runtime problem only.
It seems there is no strong relation between Jersey versions.

Create REST hello world : there is Jersey 1.8 libraries.
Delete them .
Application will be deployed without errors.

Create REST Message Board : there is Jersey 1.8 libraries.
It is possible to deploy it without errors.

Create Customer DB: there will be Jersey 1.8 libraries.
Application cannot be deployed.
Delete libraries : there is still an error.

All applications are REST spec conformed.
The only difference is additional packaged libraries and its absence 
doesn't solve the problem.


JEE6 samples don't require NB bundled Jersey library in classpath ( it solves 
the problem with Hello world app ) but this is different minor issue.
Comment 7 Petr Jiricka 2012-02-22 14:03:59 UTC
Sorry this needs to be addressed *somewhere*, so reopening. If this is a runtime problem, then please file a bug against GlassFish. If we can provide some workaround/hack on the IDE side, then we should do this even if this is a runtime problem.
Comment 8 Martin Janicek 2012-02-22 14:26:41 UTC
I can confirm that removing NB bundled Jersey library from the 
project classpath doesn't help --> it will fix Hello world sample, but both Customer Database samples are failing anyway.
Comment 9 Denis Anisimov 2012-02-22 14:36:33 UTC
Feel free to file a bug against GF.
Comment 10 Martin Matula 2012-02-22 14:38:44 UTC
I see the following in the log:

  class com.sun.jersey.oauth.server.api.resources.AccessTokenRequest
  class com.sun.jersey.oauth.server.api.resources.RequestTokenRequest
  class helloworld.HelloWorldResource
INFO: Provider classes found:
  class org.codehaus.jackson.jaxrs.JsonParseExceptionMapper
  class org.codehaus.jackson.jaxrs.JacksonJsonProvider
  class org.codehaus.jackson.jaxrs.JsonMappingExceptionMapper
  class com.sun.jersey.oauth.server.api.providers.DefaultOAuthProvider

How come there are oauth classes (the two resources and one provider) on the
class path? They are not in GF distro. So if you are not adding these to your
war, how come they are there?? Or is it throwing a different error once you
remove the jars from the war? Please provide the relevant pieces of logs
including the exceptions in cases when jars are not included in the war.
Comment 11 Martin Janicek 2012-02-22 14:48:11 UTC
I have just spoke with Tomas Kraus from Glassfish team and it doesn't look like
they can provide some easy hot-fix to get this work right now.
Denis, any ideas how to workarround this for 7.1.1?
Comment 12 Denis Anisimov 2012-02-22 14:54:43 UTC
(In reply to comment #11)
> I have just spoke with Tomas Kraus from Glassfish team and it doesn't look like
> they can provide some easy hot-fix to get this work right now.
> Denis, any ideas how to workarround this for 7.1.1?

As I already said: "Hello World" sample default settings could be changed
to get it working.
Customer DB : I have no idea how it can be changed at all.

Still even "Hello world" still has an issue if user will change 
the default settings.
So VERY limited solution for this can be applied ( only "Hello World" sample ). 
The worth of this solution is very low from mine point of view.

The bug is on the GF side and it should be fixed there.
Comment 13 Martin Janicek 2012-02-22 15:00:44 UTC
Ok, thanks. I'll provide at least small fix for Hello world sample - for now.
Comment 14 TomasKraus 2012-02-22 15:07:00 UTC
Well, I already sent this via email but I can copy-paste it here too. with trunk builds (NB 7.2 also with Jersey 1.8 /GF 4):
...
Undeploying ...
Initializing...
In-place deployment at /home/kratz/NetBeansProjects/ServletStateless/CustomerDB/CustomerDB/build/web
Initializing...
run-deploy:
BUILD SUCCESSFUL (total time: 1 second)

Customer DB works fine.
So I believe there should be some way to get this sample running with 7.1.1.
Comment 15 Denis Anisimov 2012-02-22 15:16:02 UTC
Customer DB still has unknown problem ( that's why I've said that removal Jersey 
doesn't help ) :
- Create Customer DB sample. Do not deploy it.
- Remove Jersey NB lib from classpath.
- Deploy it. All is OK.
- Add back Jersey NB bundled lib into the classpath.
- Try to deploy. There is an error.
- Remove the Jersey jars once again .
- Try to deploy. Still an error.
There is no more Jersey jars in the project classpath but it doesn't help.
Comment 16 Denis Anisimov 2012-02-22 15:17:11 UTC
(In reply to comment #13)
> Ok, thanks. I'll provide at least small fix for Hello world sample - for now.

Please don't do it.
I will fix the samples in the special way in the trunk ( 7.2 dev ).
Please just transplant the changes into  the 7.1.1 branch.
Comment 17 Martin Matula 2012-02-22 15:34:01 UTC
FYI - just to shed more light on the original issue as I think I understand it now (seeing Tomas reproducing it).

1) NetBeans seems to have one big library for all Jersey jars (including Jersey oauth modules). There is no way to include the core Jersey without including OAuth libs.
2) NetBeans uses old version of Jersey, which had an issue, that if you unintentionally added oauth resources and providers on the scanning classpath (since the hello world sample is scanning the whole classpath instead of using the package scanning feature to only scan certain packages for resources) but did not configure oauth properly it would fail - this is the core of this issue

So, there are several possible solutions:

1) bundle newer Jersey version (desirable anyway, but probably too risky at the moment)
2) split up Jersey library and use only relevant pieces for the samples (probably cleanest solution as then it will work with other containers as well, not verified though, if a different issue would occur)
3) remove Jersey jars from the war completely (probably the safest at the moment)
Comment 18 Denis Anisimov 2012-02-22 15:50:56 UTC
workaround in the trunk web-main#0ba7c7197624
Comment 19 Denis Anisimov 2012-02-22 16:11:42 UTC
It is not so easy and straight to solve.
See inline.

(In reply to comment #17)
> FYI - just to shed more light on the original issue as I think I understand it
> now (seeing Tomas reproducing it).
> 
> 1) NetBeans seems to have one big library for all Jersey jars (including Jersey
> oauth modules). There is no way to include the core Jersey without including
> OAuth libs.
True.
It is two-edged sword: we are trying to care about user as much as possible 
and trying to guess its requirements. It is not possible to understand what 
he really needs and what is optional. That's why big Jersey lib exists.
> 2) NetBeans uses old version of Jersey, which had an issue, that if you
> unintentionally added oauth resources and providers on the scanning classpath
> (since the hello world sample is scanning the whole classpath instead of using
> the package scanning feature to only scan certain packages for resources) but
> did not configure oauth properly it would fail - this is the core of this issue
GF 3.1.1 works perfectly with NB bundled Jersey. So I'm not sure that 
the problem is misconfiguration of oauth. 
> NetBeans uses old version of Jersey
True. It is not possible to have updated version of Jersey at any time. 
Jersey is updated  with each GF release.
> 
> So, there are several possible solutions:
> 
> 1) bundle newer Jersey version (desirable anyway, but probably too risky at the
> moment)
This is not a solution. See above. That will work just till new version Jersey
will be released. It is impossible to say that there will be no problem 
when newer version will be released ( current version was updated already 
some time ago).
> 2) split up Jersey library and use only relevant pieces for the samples
> (probably cleanest solution as then it will work with other containers as well,
> not verified though, if a different issue would occur)
See above. I can remove oauth jars from Jersey lib. But I'm not sure that
this is the only problem at all. 
> 3) remove Jersey jars from the war completely (probably the safest at the
> moment)
As I  already mentioned it sometimes doesn't work.
There could be a reason to have bundled Jersey lib:
- JEE5 project could be deployed onto JEE5 runtime server. JEE5 spec doesn't require REST support from the server. As result it is REQUIRED to have Jersey 
packaged with application. We can ignore JEE5 case when it will become a history.
- To make sure that the app has the same behavior across the different JEE runtime server. JEE6 spec requires REST from the server. So Jersey lib is not required to be in the classpath. But there are a number of the issues with 
requirements various Jersey jars in the project classpath. Such jars will be different for various servers and one could want to have the same fixed jars 
in the classpath. So we cannot ignore necessity of NB bundled Jersey lib.
We can just keep project classpath unchanged in case of JEE6 server.
But still there is a possibility  to change default configuration and face with the issue.
Comment 20 Martin Janicek 2012-02-22 16:42:19 UTC
There is no reason for having this issue still open. With a provided workarround it's working correctly in trunk (even both CustomerDB samples).

Jirko, please verified. I'll transplant the changes into the 7.1.1 branch after so.
Comment 21 Jiri Skrivanek 2012-02-23 10:31:18 UTC
I am afraid the fix doesn't work when you start from scratch:

- run IDE (containing the fix) with empty userdir
- register GlassFish 3.1.2 server
- create REST HelloWorld sample
- run project
- it fails with the same error as originally. It is because jersey 1.8 jars are copied into HelloWorld/build/web/WEB_INF/lib folder even they are not on classpath. It is done in build-impl.xml#library-inclusion-in-archive.
- if you add jersey 1.8 library to HelloWorld project and then remove this library, target library-inclusion-in-archive is updated that it doesn't copy jersey jars to lib folder.

Any ideas how to solve it?
Comment 22 Martin Janicek 2012-02-23 15:34:14 UTC
Fixed in: web-main #b31885d6cd48
Comment 23 Jiri Skrivanek 2012-02-24 09:26:45 UTC
Created attachment 116078 [details]
CustomeDBSpring project diff.

HelloWorld and CustomerDB work. But CustomerDBSpring works for me only with previous version when jersey1.8 jars are included in war file (see diff).
Comment 24 Quality Engineering 2012-02-24 09:29:48 UTC
Integrated into 'main-golden', will be available in build *201202240400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/0ba7c7197624
User: Denis Anisimov <ads@netbeans.org>
Log: Workaround for BZ#208706 - REST sample cannot be deployed to GlassFish 3.1.2.
Comment 25 Denis Anisimov 2012-02-24 10:04:43 UTC
(In reply to comment #23)
> Created attachment 116078 [details]
> CustomeDBSpring project diff.
> 
> HelloWorld and CustomerDB work. But CustomerDBSpring works for me only with
> previous version when jersey1.8 jars are included in war file (see diff).

web-main#8cd2b6a3a7bf

CustomerDBSpring requires com.sun.jersey.spi.resource.Singleton class which 
is not part of JEE6 spec. So the sample cannot be even compiled without it.
So Jersey libraries are required in this case.
There is no possibility at the moment to configure project with server Jersey
libraries with JEE6 profile ( see discussions about extending COMPILE classpath for web project against COMPILE_ONLY in Jersey realted issues ). 
So the only way to fix this now is using NB bundled Jersey.

This is the one more reason to use Jersey packaged libraries in the project.

All this stuff is dirty hacks actually and I don't like the situation when we 
are trying resolve the runtime issue on the IDE side.
There are definitively problems with GF :
- "Hello World" and "Customer DB" don't require Jersey in the classpath 
and works without packaged Jersey libs. They don't work with 
Jersey packaged libs.
- "Message board" and "Customer DB Spring" requires some Jersey specific
 classes to be packaged as libs. They DO WORK with NB bundled Jersey  packaged.
I have no idea what's going on.
Comment 26 Jiri Skrivanek 2012-02-24 15:33:16 UTC
I fixed small typo in Denis' last patch (main#a8b9637f17e4) and now all mentioned samples can be deployed without problem. Please, merge changes to release71_fixes. I will attach patch which represents final state against release71_fixes.
Comment 27 Jiri Skrivanek 2012-02-24 15:34:08 UTC
Created attachment 116091 [details]
Patch for release71_fixes branch.
Comment 28 Petr Jiricka 2012-02-24 15:43:09 UTC
Thanks a lot Jirka!
Comment 29 Quality Engineering 2012-02-25 10:45:09 UTC
Integrated into 'main-golden', will be available in build *201202250400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/56b4ce583ca3
User: Denis Anisimov <ads@netbeans.org>
Log: One more attempt to fix BZ#208706 - REST sample cannot be deployed to GlassFish 3.1.2.
Comment 30 Martin Janicek 2012-02-25 13:48:53 UTC
Patch integrated into release71_fixes branch: http://hg.netbeans.org/releases/rev/8fb1d9877cc0
Comment 31 Jiri Skrivanek 2012-02-27 11:05:39 UTC
Verified in NetBeans IDE 7.1.1 (Build 201202262200).