glassfish 3.1 virtual server nightmare
I m using glassfish 3.1.1 (Edition 3.1 (build 43)) server. I have deployed a web application named "void" Now I have made a virtual server where in the hosts I have written
${com.sun.aas.hostName},pradyut.dyndns.org
in network listeners I have chosen
http-listener-1
in the default web module I have chosen the web applcation named "void"
Now there are two issues:
1) Whenever I restart the server the http-sevice-1 goes offline and at every request dumps the stack trace: -
SEVERE: PWC3989: An exception or error occurred in the container during the request processing
java.lang.ClassCastException: com.sun.grizzly.config.ContextRootInfo cannot be cast to org.apache.catalina.Context
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:515)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
The solution is to
1) Undeploy the application void.
2) Restart the server.
3) Deploy application void
This was not a problem in glassfish 3.0 without the clus开发者_C百科tering(as I remember).
The second problem is whenever I make a virtual server I get the error:
INFO: webContainer.virtual-server.loadedDefaultWebModule
SEVERE: WEB0163: Exception processing HttpService configuration change
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /void deployed on virtual server void
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2034)
at com.sun.enterprise.web.WebContainer.updateHost(WebContainer.java:2916)
at com.sun.enterprise.web.WebContainer.updateHttpService(WebContainer.java:3047)
at com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:159)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:332)
at com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:114)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:379)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:369)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:259)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:257)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.Exception: No context matching /void deployed on virtual server void
at com.sun.grizzly.util.http.mapper.Mapper.addDefaultContext(Mapper.java:795)
at com.sun.grizzly.util.http.mapper.Mapper.setDefaultContextPath(Mapper.java:759)
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2026)
... 14 more
I have not got any solution to the virtual server nightmare. If you cannot replicate the above error, end the sever process from the OS task manager. then start and try.
BTW how to issue a ticket in glassfish? where is glassfish bugzilla?
I have had the same problem working with Glassfish 3.1.2.2, and after spending more time trying to fix it than I would care to admit to, I think I have a solution.
I created 8 virtual servers and tried to set default web modules on each one at a time, making sure that the application was set to run on the selected virtual server in the edit applications page (using administration console on 4848). It worked on every virtual server that came before "server" in the alphabet, and not on any virtual server coming after "server" in the alphabet. In this case the standard virtual server "server" was set as the http-listener default virtual server.
I set the http-listener's default virtual server to a new virtual server I'd named "zzz" and now I seem to be able to set default web modules for my other virtual servers without this error occurring (again, checking that the application configuration is set correctly).
In my domain.xml file the virtual servers are listed in the order added, and this has no effect on the problem. I think it is safe to say that this is a bug and not a configuration error.
I hope I've explained this well as I have just started to try and learn how servers/glassfish work.
精彩评论