Skip to main content

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

  • From: Vince Kraemer <vince.kraemer@...>
  • To: dev@...
  • Subject: Re: Is this a bug or did I just misinterpret the set-web-env-entry command?
  • Date: Tue, 18 Jun 2013 10:29:32 -0700

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





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