Skip to main content

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

  • From: Tim Quinn <tim.quinn@...>
  • To: dev@...
  • Subject: Re: Is this a bug or did I just misinterpret the set-web-env-entry command?
  • Date: Tue, 18 Jun 2013 11:46:55 -0500


On Jun 18, 2013, at 11:03 AM, Vince Kraemer wrote:

> 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.

Maybe.  Or maybe it's a bug in the web app or in you specifying 
--ignoredescriptoritem=true.

If you want to override something in the descriptor, you don't need that 
option.  Just use the "set-xxx" command.  

If you want the app to act as if something in the descriptor was never there 
in the first place, that's when you use --ignoredescriptoritem but typically 
without also specifying a value.

As you are seeing, it looks as if GlassFish sees that flag set and then gives 
that precedence over your setting of the value in the set-xxx command.  (I 
haven't checked the code but that certainly seems likely.)

Maybe the command should reject a user's attempt to both ignore the DD item 
and set a value in the same set-xxx command if that's how it's going to act 
when both are present.

So, with that meaning of --ignoredescriptoritem in mind, that's what I meant 
by specifying it possibly indicating a bug in the app.  When you tell 
GlassFish to hide the very existence of that DD item from the app, then the 
app had better be prepared to work if that item is not there.  The app is 
still looking for that name and, now that it's been suppressed by the 
--ignoredescriptoritem option, the app is failing.

- Tim


> 
> 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
>
>
> 



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

Vince Kraemer 06/18/2013

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

Tim Quinn 06/18/2013

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

Vince Kraemer 06/18/2013

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

Tim Quinn 06/18/2013

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

Vince Kraemer 06/18/2013
 
 
Close
loading
Please Confirm
Close