|
Sort Order:
I would appreciate if this could be evaluated ASAP so that if necessary a correction can be done on NetBeans side before our code freeze next week. Thanks. At the moment I consider this issue a high priority defect in GlassFish as it prevents RESTful services from running under circumstances described here. here is a transcript of a 'demo' of the issue... run against b43 (fcs bits) Notice: a restart seems to resolve the problem. I will attach the war file used in this transcript. bash-3.2$ GlassFish_Server_3.1/glassfish/bin/asadmin start-domain bash-3.2$ GlassFish_Server_3.1/glassfish/bin/asadmin restart-domain 100%[======================================================================================================>] 15,390 - 14:36:07 (357.72 MB/s) - `application.wadl.6' saved [15390/15390] used in the demo of the problem. one additional note... there wasn't a WebApplication80 deployed on the server prior to the start-domain (the first command of the demo) a bit more info... This sequence is successful when run against GF 3.0.1 b22 so this might be considered a regression bash-3.2$ GlassFish_Server_3/glassfish/bin/asadmin start-domain Command deploy executed successfully. 100%[======================================================================================================>] 15,392 - 14:54:37 (299.97 MB/s) - `application.wadl' saved [15392/15392] When trying to deploy without NetBeans, getting: remote failure: Error occurred during deployment: Exception while preparing the app : Invalid resource : jdbc/sample__pm. Please see server.log for more details. When trying from NetBeans, everything works as expected, getting the following WADL back: %curl http://localhost:8080/RESTissue/resources/application.wadl Trying to access the my.app.discountcode resource %curl -Haccept:application/xml http://localhost:8080/RESTissue/resources/my.app.discountcode My colleague, Pavel Bucek, says, the behavior is quite non-deterministic when it comes to Jersey/Servlet 3 integration. INFO: WEB0671: Loading application [RESTissue] at [/RESTissue] SEVERE: Exception while loading the app The application should not bundle Jersey JARs. When @ApplicationPath annotated application config is present The above file is present in GlassFish Jersey jersey-gf-server.jar bundle Not sure yet how to resolve this. Possible options are: 1) GlassFish web module bug, needs to be fixed there Japod, It seems like you are saying that a web app that deploys and executes successfully on 3.0.1 is not compatible with 3.1. While I guess it is possible to say that, it is a bit unexpected.... Forcing folks to repackage their working 3.0.1 apps for 3.1 seems like an impediment to adoption of 3.1. Forcing folks to repackage apps that are working on Tomcat and the like to be 3.1 compatible seems like a burden, too. Vince, in terms of executes successfully on 3.0.1 and not compatible with 3.1: Regarding the Tomcat point: Tomcat is not a Java EE 6 compatible container, it does not have Anyway: i am not a magician a can not fix 3.1, that game is over, i can only try to help fixing 3.1+. So back to the matter: apart from the class ambiguity it seems there is indeed a bug in the GlassFish web module. -
Namely the application classes that extend or implement given types are omitted in the list. You might want to try to set the "org.glassfish.web.parsing" system property to true on your container, ~Jakub |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Closed
Major
Registering the Jersey servlet application DOES NOT happen
It is easy to reproduce this also without NetBeans:
Unzip RESTissue.tar.gz which is attached to this issue and you will find there RESTissue/dist/RESTissue.war. Deploy it via asadmin and once it is deployed you use
"wget http://localhost:8080/RESTissue/resources/application.wadl
"
to retrieve wadl file. It will fail (404) because "resources" servlet is simply not running.
Now, open RESTissue.war again and remove all jars from its WEB-INF/lib folder (15 jars which comprise 'Jersey 1.3' library) and redeploy the modified war and now wget will retrieve wadl file.