quality@glassfish.java.net

[Fwd: Re: Problem with virtual servers]

From: Sankar Neelakandan <Sankar.Neelakandan_at_Sun.COM>
Date: Wed, 16 Sep 2009 09:24:35 -0700

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