Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 199383 - Ability to use Grizzly Web Server as web container
Ability to use Grizzly Web Server as web container
Status: NEW
Product: serverplugins
Classification: Unclassified
Component: GlassFish
All All
: P3 (vote)
Assigned To: Vince Kraemer
Depends on:
  Show dependency treegraph
Reported: 2011-06-13 18:14 UTC by _ gtzabari
Modified: 2013-03-20 00:08 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2011-06-13 18:14:21 UTC
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.
Comment 1 Petr Jiricka 2013-03-14 20:53:12 UTC
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?
Comment 2 TomasKraus 2013-03-16 00:25:46 UTC
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.
Comment 3 Petr Jiricka 2013-03-19 09:24:43 UTC
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.
Comment 4 _ gtzabari 2013-03-20 00:08:51 UTC
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.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo