dev@glassfish.java.net

Re: Is this a bug or did I just misinterpret the set-web-env-entry command?

From: Vince Kraemer <vince.kraemer_at_oracle.com>
Date: Tue, 18 Jun 2013 09:03:11 -0700

Thanks Tim...

I forgot about disable/enable.

I will open an issue for the docs.

I think I discovered something that does look like a bug.

I did this...


vbkmbp:~ vkraemer$ /Applications/NetBeans/glassfish-4.0/bin/asadmin
set-web-env-entry --name EnvEntryName --value NewerEnvEntryValue --type
java.lang.String --ignoredescriptoritem=true AppWithEnvEntryAndContextParam6
Previous env-entry setting of EnvEntryName for application/module
AppWithEnvEntryAndContextParam6 was overridden.
Command set-web-env-entry executed successfully.

vbkmbp:~ vkraemer$ /Applications/NetBeans/glassfish-4.0/bin/asadmin
disable AppWithEnvEntryAndContextParam6
Command disable executed successfully.

vbkmbp:~ vkraemer$ /Applications/NetBeans/glassfish-4.0/bin/asadmin
enable AppWithEnvEntryAndContextParam6
Command enable executed successfully.

vbkmbp:~ vkraemer$ curl
http://localhost:8080/AppWithEnvEntryAndContextParam6/NewServlet
<!DOCTYPE html>
<html>
<head>
<title>Servlet NewServlet</title>
</head>
<body>
<h1>Servlet NewServlet at /AppWithEnvEntryAndContextParam6</h1>
</body>
</html>

I noticed this in the server log...

[2013-06-18T08:54:15.455-0700] [glassfish 4.0] [SEVERE] [] [] [tid:
_ThreadID=20 _ThreadName=Thread-4] [timeMillis: 1371570855455]
[levelValue: 1000] [[
   javax.naming.NamingException: Lookup failed for
'java:comp/env/EnvEntryName' in
SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl,
java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception
is javax.naming.NameNotFoundException: No object bound to name
java:comp/env/EnvEntryName]
         at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
         at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
         at javax.naming.InitialContext.lookup(InitialContext.java:411)
         at javax.naming.InitialContext.lookup(InitialContext.java:411)
         at my.NewServlet.processRequest(NewServlet.java:48)
         at my.NewServlet.doGet(NewServlet.java:77)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
         at
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
         at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
         at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
         at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
         at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
         at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
         at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
         at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
         at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
         at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
         at
org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
         at
org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
         at
org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
         at
org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
         at
org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
         at
org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
         at
org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
         at
org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
         at
org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
         at
org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
         at
org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
         at
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
         at
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
         at
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
         at
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
         at
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
         at java.lang.Thread.run(Thread.java:722)
Caused by: javax.naming.NameNotFoundException: No object bound to name
java:comp/env/EnvEntryName
         at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:741)
         at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
         at
com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:159)
         at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
         ... 34 more]]
On 6/18/13 4:43 AM, Tim Quinn wrote:
> Hi, Vince.
>
> Ultimately it's up to the respective container to decide how to deal with these dynamic reconfiguration commands.
>
> Having said that, I worked on the initial implementation of this bit of functionality quite a while back (while on the deployment team). Someone from deployment team or the web team might have more recent information, but I think if you disable and then re-enable the affected app you will then see the effects you expect. This effectively restarts the application - so the configuration changes can take effect - without restarting the entire server.
>
> Can you try that?
>
> IIRC the thinking at the time was that an application might use one or more of the dynamically reconfigurable items during its start-up. It could lead to inconsistent (and therefore surprising) or incorrect results if the container used a newly-modified setting immediately, given that the app would have started up with the old, unchanged value. So requiring an app restart made sure that the app always ran with a consistent set of configuration information.
>
> I took a quick look at the published documentation and I did not see it mentioned that users must restart the app for the changes to take effect. That's probably worth a JIRA issue.
>
> - Tim
>
>