Hi, Laird.
I just tried the same experiment using a very new build (source
checked out and rebuilt this morning). I get the same behavior at the
browser which you reported, but my server.log contained a different
error (pasted below).
Might be time for a new issue.
- Tim
[#|2011-11-29T15:31:32.538-0600|SEVERE|glassfish3.1.2|
org.apache.catalina.connector.CoyoteAdapter|
_ThreadID=26;_ThreadName=Thread-2;|PWC3989: An exception or error
occurred in the container during the request processing
java.lang.IllegalStateException: PWC2776: invalidate: Session already
invalidated
at
org
.apache
.catalina.session.StandardSession.invalidate(StandardSession.java:1467)
at
org
.apache
.catalina
.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:
204)
at
org
.glassfish
.admingui
.common
.security
.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:280)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider
$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:1171)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1452)
at
com
.sun
.web
.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:
1330)
at
org
.apache
.catalina
.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at
org
.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:
623)
at
org
.apache
.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at
com
.sun
.enterprise
.web
.PESessionLockingStandardPipeline
.invoke(PESessionLockingStandardPipeline.java:91)
at
org
.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
162)
at
org
.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:
331)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
231)
at
com
.sun
.enterprise
.v3.services.impl.ContainerMapper.service(ContainerMapper.java:232)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:833)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:730)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1031)
at
com
.sun
.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:
228)
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:680)
On Nov 29, 2011, at 3:22 PM, Laird Nelson wrote:
> Hello; some of my developers are reporting that with Glassfish 3.1.2
> build 9 any attempt to access the administration console remotely
> (from a different machine's web browser) fails.
>
> Here are the steps to reproduce the problem:
>
> Install Glassfish normally.
>
> Start the server:
> asadmin start-domain
>
> Change the administration password:
> asadmin change-admin-password
> Enter admin user name [default: admin]> admin
> Enter admin password> <return>
> Enter new admin password> somepassword
> Enter new admin password again> somepassword
> Command change-admin-password executed successfully.
>
> Enable "secure admin":
> asadmin enable-secure-admin
> Enter admin user name> admin
> Enter admin password for user "admin">
> Command enable-secure-admin executed successfully.
>
> Stop the server:
> asadmin stop-domain
>
> Start the server:
> asadmin start-domain
>
> Now navigate to that machine's port 4848 from another box. Put in
> admin for the username and somepassword for the password.
>
> A blank screen results (the URL reflects the j_security_check
> destination).
>
> The log file says, in part:
> Caused by: java.io.EOFException: SSL peer shut down incorrectly
> at
> com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:333)
> at
> com
> .sun
> .net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
> ... 57 more
>
>
> I noticed lots of JIRAs related to SSL errors, but they all appear
> to have been fixed. Is this a new error, a regression, or...?
>
> Thanks as always,
> Laird
>
> --
> http://about.me/lairdnelson
>