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.
I propose supporting Grizzly as a lightweight alternative to Glassfish/Tomcat for developing and testing web application in Netbeans. Glassfish/Tomcat are great for production but consider the following: 1. Grizzly takes 1 second to launch. Glassfish over 20 seconds. 2. All JNI, Classloader, Memory Leak problems we are currently encountering when reloading webapps during development could be fixed by simply restarting the entire web container's JVM if we were using Grizzly. Reloading would still be quick and all the aforementioned problems would disappear. 3. I assume you will be able to reuse much of the Glassfish plugin implementation for Grizzly.
I just found this enhancement request. Regarding: > 3. I assume you will be able to reuse much of the Glassfish plugin implementation for Grizzly. I am not sure, as the NetBeans GlassFish plugin probably relies on some admin services of GlassFish, which are not a part of Grizzly itself. Tomas?
Plugin uses 2 ways of accessing glasfish - old asadmin HTTP interface or new (not yet finished) REST interface. I have no idea what's admin interface for Grizzly, but I can ask local development team.
Based on some internal conversation, actually Grizzly uses a different approach to administration than GlassFish, so reusing the GlassFish plugin codebase would not be possible - you would have to implement the plugin for Grizzly from scratch. Also one question that comes to my mind, what exactly do you "deploy" to Grizzly? For example if you use Maven, the GlassFish plugin assumes that you have a war packaging type, and you deploy either a war file or expanded war directory. With Grizzly this would need to work differently, right? I don't have any experience with development against Grizzly - can you please share your experience and expectations, so we have an idea how this should work? Thanks.
I am expecting Grizzly to behave the same as an embedded Jetty web server (or you can simply provide better Jetty integration instead of Grizzly). I like using an embedded Jetty server for the following reason: 1. The webapp (either in WAR or unpacked form) is treated as a stand-alone Java application. 2. There is no class sharing between applications, nor any possibly memory leaks because restarting the webapp entailed restarting the application (launching a new JVM). 3. App startup/shutdown is extremely quick (1-2 seconds max). 4. Jetty goes a step further and monitors unpacked webapps for changes. When I update an HTML file, the server begins serving the new version immediately. I can simply reload the browser window to see the new version; no need to restart the webapp.