quality@glassfish.java.net

RE: strange behaviour of opensso on glassfish V3 Prelude (b28c)

From: Wim Verreycken <wim_at_pizzastop.be>
Date: Sun, 23 Nov 2008 00:06:49 +0100

Ola, addendum.

The installtion of opensso also causes problems shutting down gf server. To
this moment, it is still running (although netbeans shows it as off). So
server.log attached is not complete.
Here's the rest of it (up to this point, I'm gonna kill it now, since it
didn't do anything anymore for the last 20 minutes or so).

Wim

PS. After removing opensso from the server, it shuts down fine.

-----Original Message-----
From: Wim Verreycken [mailto:wim_at_pizzastop.be]
Sent: zaterdag 22 november 2008 23:54
To: quality_at_glassfish.dev.java.net
Subject: strange behaviour of opensso on glassfish V3 Prelude (b28c)

Hi everyone,


I've tested the latest two opensso releases (Express 5 and Enterprise 80) on
Glassfish b28c.
(removed all config files before deployment, as I'm used to).

No errors were shown while autodeploying on glassfish, nor any during the
default installation of opensso. (Debug mode)
(Create default configuration).

In the default configuration, one only has to enter the password for amAdmin
and UrlAccessAgent.

Strangely, after installation I cannot login to the admin console using the
password provided during installation.

I also tried http://host.domain/deployurl/UI/Login?module=DataStore as a
test, but no difference. (Release notes state this is only necessary if one
is not using the DataStore authentication module on the root realm - clearly
not the case, even the login page states " This server uses Data Store
Authentication" - but I tried it anyway)

After login, one is simply redirected back to the logon page, not the admin
console. No validation/authentication errors are shown either.
This opposed to the situation when a false password is provided. Then the
auth page clearly says : "Authentication failed", and a link back to the
logon page is provided.

This lead me to believe the problem is somewhere in the redirection, and the
actual authentication is done correctly (I would have to test further).

After closer inspection of server.log I do see an unaccounted for
NumberFormatException, and some dependency failure in jvm.log
(Attached, don't mind the EJB/SQL exceptions pls, this is due to a DB pool
that is not configured properly for another app - should not be related)

I have tested both versions of opensso on Tomcat 6.0.18 as well.
The problem does not exist on TC, which leads me to believe this is a
glassfish issue, and was worth mentioning here.

Also, since Glassfish is stated on the opensso page as the "preferred
application server" for running opensso, I thought this is an issue which
should to be looked into. After all it would be a big bummer if someone gave
this combo a quick try on a windows box.

OS : Windows XP Version 2002 SP3
JDK : 1.6.0_06
GF : b28c

Has anyone else experienced this behaviour?
Any further steps required/desired from my side?


Thanks,

Wim