Closed glassfishrobot closed 16 years ago
glassfishrobot
commented
6 years ago glassfishrobot
commented
16 years ago @glassfishrobot Commented jluehe said: Taking a look. I think this has to do with the Mapper[] that gets initially injected into the WebContainer not having any entry for the newly created listener.
glassfishrobot
commented
16 years ago @glassfishrobot Commented jluehe said: Fixed, as follows:
In WebContainer.addConnector(), retrieve the Mapper of the new http-listener from the habitat (where it was added by a call to GrizzlyService.createNetworkProxy()), and set it on the new http-listener before the http-listener is started.
In GrizzlyService.removeNetworkProxy(), call newly added destroy() method on GrizzlyProxy, which causes the proxy's Mapper to be purged from the habitat (this is to prevent duplicate Mapper objects for the same port should an http-listener be deleted and later recreated)
svn commit -F /home/luehe/log Sending core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyProxy.java Sending core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyService.java Sending core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/NetworkProxy.java Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java Transmitting file data .... Committed revision 21604.
There is still a problem with dynamic creation of http-listener, though. Right now, WebContainer.addConnector() (which causes the Http listener's Mapper object to be created) is called only if the web container has already been started by the time the new http-listener is created. In other words, the scenario where a webapp has been deployed, and a new http-listener is created (which I believe is the scenario you tested and for which you filed a bug), now no longer throws any NPE, but the scenario where the new http-listener is created before any webapp has been deployed (i.e., before the web container has been started) still does not work for me.
Can you please verify? Thanks!
glassfishrobot
commented
16 years ago @glassfishrobot Commented @amyroh said: Thanks for the fix Jan!
Yes, the current dynamic reconfiguration works only if the web container has been started (at least one webapp is deployed previously) because HttpServiceConfigListener (dynamic reconfig listener) is instantiated in WebContainer.postConstruct().
Is this an acceptable behavior? Should we move the instantiation elsewhere so dynamic reconfig works even when the web container hasn't been started?
glassfishrobot
commented
16 years ago @glassfishrobot Commented jluehe said: Hi Amy, yes, we need to support dynamic creation of http-listeners regardless of whether the web container has been started or not.
The problem right now is that when you create an http-listener before you've deployed any WAR file, asadmin reports:
Command create-http-listener executed successfully
and the http-listener is added to the domain.xml, however, GrizzlyService never created any Mapper for it and registered it with the habitat, which will cause the new http-listener to fail to start (with an NPE) when a WAR is deployed and the web container started, because the Connector's startup code assumes that a Mapper has been set. But in this case, a Mapper was never created.
I think technically you are right that supporting the creation of an
http-listener before the web container has been started does not make much
sense. In this case, instead of creating an http-listener, one really should
create a new network listener (once the new
Does this make sense? 
glassfishrobot
commented
16 years ago @glassfishrobot Commented jluehe said: Perhaps "asadmin create-http-listener" (and all the other webtier related commands) should start the web container if it has not already been started?
glassfishrobot
commented
16 years ago @glassfishrobot Commented Was assigned to jluehe
glassfishrobot
commented
7 years ago @glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-5427
glassfishrobot
commented
16 years ago @glassfishrobot Commented Reported by @amyroh
glassfishrobot
commented
16 years ago @glassfishrobot Commented Marked as fixed on Wednesday, August 6th 2008, 2:05:31 am
Newly created http-listener cannot be dynamically started with NPE in MapperListener. This is a regression since this used to work before recent mapping changes. Can be easily reproduced with asadmin create-http-listener command.
[#|2008-08-04T12:23:33.247-0700|INFO||javax.enterprise.system.container.web|_ThreadID=15;_ThreadName=Thread-3;|Created HTTP listener test-listener|#]
[#|2008-08-04T12:23:33.266-0700|INFO||global|_ThreadID=15;_ThreadName=Thread-3;|Listening on port 7777|#]
[#|2008-08-04T12:23:33.268-0700|SEVERE||javax.enterprise.system.container.web|_ThreadID=15;_ThreadName=Thread-3;|Exception while processing config bean changes : java.lang.NullPointerException at org.apache.catalina.connector.MapperListener.init(MapperListener.java:199) at com.sun.enterprise.web.WebConnector.start(WebConnector.java:63) at com.sun.enterprise.web.WebContainer.addConnector(WebContainer.java:4267) at com.sun.enterprise.web.reconfig.HttpServiceConfigListener$1.changed(HttpServiceConfigListener.java:131) at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:278) at com.sun.enterprise.web.reconfig.HttpServiceConfigListener.changed(HttpServiceConfigListener.java:113) at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:215) at org.jvnet.hk2.config.Transactions$ListenerInfo$1.run(Transactions.java:115) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
| #] |
Environment
Operating System: All Platform: All
Affected Versions
[V3]