Hi Tim,
OK... I think I understand what these options mean now...
I will open a doc issue for the man page because it is pretty opaque.
It may be useful to put the effect into terms that leverages the
'objects' that people are using.
Changing the doc to translate the effect into a description of the edits
that would take place in an 'effective' deployment descriptor may
clarify the effect of the command.
A warning about "don't mix --type/--value with
--ignoredescriptoritem=false... because it is a nonsensical command" may
be worth an issue, too.
vbk
On 6/18/13 9:46 AM, Tim Quinn wrote:
> 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
>>>
>>>