Created attachment 115986 [details]
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)
It fails also for other REST samples from this category.
Stopper for 7.1.1 ... please evaluate ASAP. Thanks in advance.
Cc'ing also Denis - Denis and Martin, can you please investigate ASAP? Thanks.
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
That will work for J2EE servers supported JEE6.
Verified with trunk builds (NB 7.2, GF 4) and see the same problem.
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.
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.
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.
Feel free to file a bug against GF.
I see the following in the log:
INFO: Provider classes found:
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.
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?
(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.
Ok, thanks. I'll provide at least small fix for Hello world sample - for now.
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):
In-place deployment at /home/kratz/NetBeansProjects/ServletStateless/CustomerDB/CustomerDB/build/web
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.
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.
(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.
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)
workaround in the trunk web-main#0ba7c7197624
It is not so easy and straight to solve.
(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.
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
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
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.
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.
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?
Fixed in: web-main #b31885d6cd48
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).
Integrated into 'main-golden', will be available in build *201202240400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Denis Anisimov <firstname.lastname@example.org>
Log: Workaround for BZ#208706 - REST sample cannot be deployed to GlassFish 3.1.2.
(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).
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.
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.
Created attachment 116091 [details]
Patch for release71_fixes branch.
Thanks a lot Jirka!
Integrated into 'main-golden', will be available in build *201202250400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Denis Anisimov <email@example.com>
Log: One more attempt to fix BZ#208706 - REST sample cannot be deployed to GlassFish 3.1.2.
Patch integrated into release71_fixes branch: http://hg.netbeans.org/releases/rev/8fb1d9877cc0
Verified in NetBeans IDE 7.1.1 (Build 201202262200).