Salut,
this issue has been fixed:
*
http://is.gd/3louU
with b63. It may not fix the problem reported with the previous email,
but ask the user to try and see.
A+
-- Jeanfrancois
Sankar Neelakandan wrote:
> copying to to users_at_gf
>
> -------- Original Message --------
> Subject: Re: Problem with virtual servers
> Date: Wed, 16 Sep 2009 15:05:28 +0200
> From: Cserep Janos <cserepj_at_szeretgom.hu>
> Reply-To: quality_at_glassfish.dev.java.net
> To: quality_at_glassfish.dev.java.net
> References: <65ded6530909160429u7ad11945q6af95de17961ad0c_at_mail.gmail.com>
>
>
>
> One exception I've found in the server.log that may be related to this:
>
> [#|2009-09-16T15:03:50.954+0200|SEVERE|glassfish|grizzly|_ThreadID=1682;_ThreadName=Thread-2;|No
> host found: __asadmin|#]
>
> [#|2009-09-16T15:03:50.954+0200|WARNING|glassfish|org.apache.catalina.connector.MapperListener|_ThreadID=1682;_ThreadName=Thread-2;|Error
> registering contexts
> java.lang.ArrayIndexOutOfBoundsException: -1
> at
> com.sun.grizzly.util.http.mapper.Mapper.addContext(Mapper.java:330)
> at
> org.apache.catalina.connector.MapperListener.registerContext(MapperListener.java:608)
> at
> org.apache.catalina.connector.MapperListener.init(MapperListener.java:223)
> at
> org.apache.catalina.connector.Connector.start(Connector.java:1789)
> at
> com.sun.enterprise.web.connector.coyote.PECoyoteConnector.start(PECoyoteConnector.java:581)
> at
> com.sun.enterprise.web.WebContainer.updateConnector(WebContainer.java:2963)
> at
> com.sun.enterprise.web.WebContainer.updateHost(WebContainer.java:2762)
> at
> com.sun.enterprise.web.reconfig.HttpServiceConfigListener$1.changed(HttpServiceConfigListener.java:121)
> at
> org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:314)
> at
> com.sun.enterprise.web.reconfig.HttpServiceConfigListener.changed(HttpServiceConfigListener.java:108)
> at
> org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:351)
> at
> org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:341)
> at
> org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:234)
> at
> org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:232)
> 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)
> |#]
>
>
> This happens when I change the default web module property in the admin
> gui and click on save.
>
> 2009/9/16 Cserep Janos <cserepj_at_szeretgom.hu <mailto:cserepj_at_szeretgom.hu>>
>
> Hi,
>
> I'm running Glassfish v3 build 63 on OpenSolaris x86 and run into a
> nasty issue with virtual servers.
>
> My current domain.xml can be found here:
>
> http://www.metaprime.hu/domain.xml
>
> As you see I have multiple virtual servers defined, the setup in
> domain.xml is very similar for all of them. The problem is one of
> them is not working: the web application caissa is not reachable on
> / as the default web module of the virtualserver ccb. It can be
> reached on /caissa on virtualserver ccb however.
>
> I've checked sun-web.xml and web.xml but found nothing related to
> this particular webapp in them which would prevent Glassfish to map
> it on / for a virtual server. And it worked with a previous build.
>
> After a number of restarts which involved undeploying the
> application, deleting the virtual server, creating the vs without
> default web module, deploying the app, modifying the app to the
> virtual server, modifying virtual server to have the default web
> module and then again saving the app I've finally managed to get it
> working a few days ago, but a recent app server restart again has me
> in the same state: one of the virtual servers is not working and I
> can no longer reproduce what I did to get it working during the weekend.
>
> What's interesting is that /index.html shows the file from the
> default virtual server's docroot, not the ccb's as long as the
> application is deployed. Once I undeploy it, the correct virtual
> server's docroot is listed.
>
> Is this a known problem?
>
> Thanks,
>
> Janos
>
>
>