<< Back to previous view

[GLASSFISH-15544] [BLOCKING] Cannot login to GUI after upgraded from v2 applying Glassfish 2.1.1Patch8 Enterprise profile Created: 12/Jan/11  Updated: 17/Feb/11  Due: 18/Jan/11  Resolved: 19/Jan/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b35
Fix Version/s: 3.1_b39

Type: Bug Priority: Critical
Reporter: sss150302 Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris sparc


File Attachments: JPEG File adminconsole-auth-module.jpg     JPEG File console-screen-b38.jpg     XML File domain_after_upgrade.xml     XML File domain_before_upgrade.xml     Text File server-cannotCreatClassLoader.log     Text File server.b38.log     Text File server.log     Text File upgrade-31-b38.log     Text File upgrade-31-b39-nightly-20-jan-2011.log     PNG File upgraded-admin-b35-jdk6u23.png    
Issue Links:
Dependency
blocks GLASSFISH-15157 [UB]Instructions for upgrade from v2 ... Resolved
Tags: 3_1-approved 3_1-blocking 3_1-upgrade 3_1-verified EE Enterprise HADB
Participants: Anissa Lam, Bobby Bissett, kumarjayanti, sirajg, sss150302 and Tim Quinn

 Description   

Glassfish 2.1.1 Patch8 to 3.1 B35 Upgrade in Enterprise profile.

Follow the steps as per http://java.net/jira/browse/GLASSFISH-15108

After upgrade try to load the admin console at 4848, it does not load and throws a
" Authentication failed " message. Please see the attachment upgraded-admin-b35-jdk6u23.png



 Comments   
Comment by Anissa Lam [ 12/Jan/11 08:04 AM ]

We tested that GUI launches ok for cases where secure is NOT turned on. It looks to me that secure is turned on for this test case.
I have just fixed GLASSFISH-15421 which is related to secure admin.
Can you try again with 11/12 nightly build to see if you see different result ?

Comment by Bobby Bissett [ 12/Jan/11 08:23 AM ]

Any changes to the users' steps for an EE profile upgrade need to go into the wiki page. I'm adding a depends link for the doc issue to this one.

Am updating my workspace now and will try this again.

Comment by Anissa Lam [ 12/Jan/11 08:39 AM ]

Can you also see if it makes any difference in regards to GUI before and after applying the patch specified ?
thanks

Comment by Bobby Bissett [ 12/Jan/11 09:53 AM ]

I'm using revision 44443 of the workspace. I did the jvm-option changes and copied the files specified in the pre-upgrade steps and then did the upgrade. After starting the server and heading to the admin url, I'm prompted for username/password without any issues. But I can't log in after this. I'm using the same admin username/password I had on the v2.1.1 installation, and I know this info is correct because I can use it with a call to 'asadmin login' and it succeeds. FWIW, I also tried admin:adminadmin and admin:'' (no password) without success.

The only message in the server log is this whenever I try to log in:

[#|2011-01-12T12:48:19.455-0500|WARNING|glassfish3.1|org.apache.catalina.connector.Request|_ThreadID=26;_ThreadName=Thread-1;|PWC4011: Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called|#]

So this bug as written could be marked fixed and a new one opened; whatever you'd like to do.

Comment by Bobby Bissett [ 12/Jan/11 09:54 AM ]

Oops, when I wrote "So this bug as written could be marked fixed..." I meant that the console does load. We just can't log into it. Perhaps the summary should be changed.

Comment by Anissa Lam [ 12/Jan/11 10:56 AM ]

Thanks Bobby for trying this out.
If user cannot login, seems to be security or web container issue. Not much GUI can do.
Is your experience the same whether you apply the patch specified ?
thanks

Comment by sirajg [ 12/Jan/11 11:07 AM ]

Also, Bobby, is secure admin enabled in this case?

Comment by Bobby Bissett [ 12/Jan/11 11:22 AM ]

Anissa: I'm not sure what patch you mean. Can you clarify?

Siraj: Um, maybe? I'll attach the domain.xml both before and after the upgrade if that helps.

Comment by Bobby Bissett [ 12/Jan/11 11:23 AM ]

Added domain.xml before/after the upgrade.

Comment by Bobby Bissett [ 12/Jan/11 11:30 AM ]

Ok, trying again.

Comment by Anissa Lam [ 12/Jan/11 12:15 PM ]

>> Anissa: I'm not sure what patch you mean. Can you clarify?
Oh, I mean the Glassfish 2.1.1Patch8 Enterprise profile thats mentioned in the bug report.

Comment by Bobby Bissett [ 12/Jan/11 12:22 PM ]

Hi Anissa,

I think the patch is included in the installer. The installer I used is called sges_ee-2_1_1-p08-solaris-sparc.bin.

Comment by Anissa Lam [ 12/Jan/11 12:37 PM ]

As far as I can tell, GUI behaves properly.
It loaded up correctly, detects that anonymous login is not allowed and display the login page.
From that point on, If authentication failed, it is not a GUI issue.
I don't know if this is a security or web container issue.
Let me start with web container first.

Comment by kumarjayanti [ 12/Jan/11 06:03 PM ]

Can someone attach the server.log so i can quickly see what the error is ?.

Comment by kumarjayanti [ 12/Jan/11 06:09 PM ]

I see comments from Bobby indicating server.log had nothing useful:

[#|2011-01-12T12:48:19.455-0500|WARNING|glassfish3.1|org.apache.catalina.connector.Request|_ThreadID=26;_ThreadName=Thread-1;|PWC4011: Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called|#]

If authentication had to really fail at the security layer we will see an info log about the failed authentication.

Can someone do a cat admin-keyfile and paste it on this bug.

Comment by sss150302 [ 12/Jan/11 08:46 PM ]

cat domain1/config/keyfile
#

  1. Copyright 2004 Sun Microsystems, Inc. All rights reserved.
  2. SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
    #
  1. List of users for simple file realm. Empty by default.
Comment by kumarjayanti [ 12/Jan/11 08:53 PM ]

hi

i asked to cat admin-keyfile not keyfile.

please cat the contents of admin-keyfile

Comment by sss150302 [ 12/Jan/11 08:58 PM ]

cat admin-keyfile
admin;{SSHA}qetWv1Zn0cWqP59GgnLCh5iW8Jom27XDLKFEKg==;asadmin

  1. Domain User and Password - Do Not Delete Entry Above
Comment by kumarjayanti [ 12/Jan/11 09:35 PM ]

i have put this admin-keyfile in a normal GlassFish V3.1 instance and then i have no problem loggin in as admin/adminadmin

So can you tell me what happens in the admin console after you click login. Are you seeing any response such as authentication failed or does it just hang.

Comment by sss150302 [ 12/Jan/11 09:43 PM ]

I get a Authentication Failed message, the same message if I try again. It does not hang screenshot is attached.
You can take a look at my system : ejp-156s-46.india (aroot/abc123) : /space/31/upgrade/glassfish3/

Comment by kumarjayanti [ 12/Jan/11 11:47 PM ]

where is the right java on that test system. I am default java is 1.5

Comment by sss150302 [ 12/Jan/11 11:55 PM ]

source /space/31/upgrade/setenv.sh which sets java version to 1.6.0_23

Comment by kumarjayanti [ 13/Jan/11 02:24 AM ]

Debugged the problem. We see that during the process of loading the console and till the point the login-form appears, there are several calls to __anonymous-user-enabled (SecurityUtil.getAnonymousUser()). All those calls reach the Backend Security Realm with username="admin" and password="".

However after the login form is thrown to the user and we enter username="admin", password="adminadmin" there is no call to the Security Realm Backend to validate this user.

Instead there is this comment in AdminConsoleAuthModule, which seems to say, it should use Rest Authentication:

-----------------
// Don't use the PasswordValidationCallback... use REST authorization instead.
// char[] pwd = new char[password.length()];
// password.getChars(0, password.length(), pwd, 0);
// PasswordValidationCallback pwdCallback =
// new PasswordValidationCallback(clientSubject, username, pwd);

// Make REST Request
WebResource webResource = Client.create().resource(restURL);
webResource.addFilter(new HTTPBasicAuthFilter(username, password));
ClientResponse resp = webResource.accept(RESPONSE_TYPE).post(ClientResponse.class);
RestResponse restResp = RestResponse.getRestResponse(resp);

// Check to see if successful..
if (restResp.isSuccess()) {
---------------------

And this restResp.isSuccess() returns false here. This causes the authmodule to send an Error Page back to the Browser.

Attached is the screen shot of the debug session, showing the correct username/password and showing that restResp.isSuccess() is returning false in this case.

Comment by kumarjayanti [ 13/Jan/11 02:27 AM ]

Debug session showing problem with RestAuthorization

Comment by Anissa Lam [ 13/Jan/11 07:59 AM ]

Thanks Kumar for looking into this.
We have a hard time setting up the environment because downloading the 2.1.1 patch 8 installer from IEC is so slow that it just doesn't work.
Since you have the env setup, can you try to see if you get go http://<hostname>:4848/management/domain ? The same way as you access GUI but with management/domain in the URL.
thanks

Comment by Bobby Bissett [ 13/Jan/11 09:43 AM ]

When I try hitting <host>:4848/management/domain on my system, it lets me in after a basic auth check. But <host>:4848 still fails as above.

Comment by Anissa Lam [ 13/Jan/11 10:22 AM ]

Based on Bobby's previous comment, doesn't seem to be a REST issue.
I'll take this and look into this.

Comment by Anissa Lam [ 13/Jan/11 10:59 AM ]

I finally have this 2.1.1 patch 8 installed on my Solaris Sparc.
Can someone post the exact steps on how to reproduce it ?
I did see "Follow the steps as per http://java.net/jira/browse/GLASSFISH-15108" , however, that bug report has lots of discussion, and many steps, workaround to try out etc. It is too hard to follow.
Please help me to reproduce the problem quickly so i can work on it.
thanks

Comment by Anissa Lam [ 13/Jan/11 11:17 AM ]

comment removed to not cause confusion.

Comment by Bobby Bissett [ 13/Jan/11 12:10 PM ]

Assuming you get set up, here are some simplified instructions for seeing this issue.

I'm assuming you have SUNWappserver and glassfish3 both installed under <somedir> and you're in <somedir>. Refer to these instructions below: http://wikis.sun.com/display/GlassFish/NSS+upgrade+instructions

1. Copy SUNWappserver/domains/domain1 to <somedir>. That way you can edit it without clobbering the original.

2. Copy the three files specified above from glassfish3/glassfish/domains/domain1/config to ./domain1/config.

3. Edit ./domain1/config/domain.xml according to the pre-upgrade steps above.

4. Perform the upgrade with:
./glassfish3/glassfish/bin/asupgrade -s ./domain1 -t ./glassfish3/glassfish/domains -c
...that will rename your 3.1 domain1 to domain1.original, copy ./domain1 to the 3.1 domains dir, and perform the upgrade. When prompted for master password, just accept the default since the original was overwritten in step 2 above.

5. Now start up the 3.1 server and you're all set to try logging into the admin console. For your copy/paste pleasure:
./glassfish3/glassfish/bin/asadmin start-domain domain1

Comment by Anissa Lam [ 13/Jan/11 02:40 PM ]

Bobby gave me a tar ball for the domain and a few steps so i can reproduce that on Mac.
I followed, i can startup the upgraded domain, go to :4848/manage/domain , deploy hello.war and launch that.
However, I cannot get GUI to get up far enough to go to the login screen. It dead earlier for not able to create classloader.

Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:594)
at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:178)
at java.lang.ClassLoader.<init>(ClassLoader.java:207)
at org.glassfish.admingui.common.plugin.ConsoleClassLoader.<init>(ConsoleClassLoader.java:86)
... 65 more

#]

I am attaching server-cananotCreateClassLoader.log
I am blocked by this.

Comment by Anissa Lam [ 13/Jan/11 05:44 PM ]

I am able to fix my solaris sparc, install 2.1.1 patch8 and start the v2 server.
I followed the instructions to upgrade and FINALLY see the login screen which of course always gives authentically failed as reported here.
All this happened on the Solaris.

If i test my luck, copy this upgraded domain/config directory to my Mac, and start it. I got the same experience as using the 'upgraded domain' that Bobby zip up for me. ie, I can go to REST , deploy hello.war, launch it, but I can't startup GUI.

Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:594)
at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:178)
at java.lang.ClassLoader.<init>(ClassLoader.java:207)
at org.glassfish.admingui.common.plugin.ConsoleClassLoader.<init>(ConsoleClassLoader.java:86)
... 65 more

#]

My debugging will made easier if someone can tell me what may cause this so i can debug on my Mac.

But for the time being, I can dig into this using my 10 years old 1G memory Solaris box

Comment by kumarjayanti [ 13/Jan/11 08:33 PM ]

You will need to put the code in ConsoleClassLoader in a doPrivileged block when System.getSecurityManager() returns non-null.

Comment by Anissa Lam [ 13/Jan/11 08:55 PM ]

Kumar, can you tell me why I only see this class loader issue on Mac ? With Solaris, it doesn't get into this issue, but gets going further, like what you experienced, that it is able to bring up the login screen.

Comment by kumarjayanti [ 13/Jan/11 09:42 PM ]

not sure. It maybe due to the JDK version then. I am assuming you have the latest workspace on the MAC right ?.

Comment by Anissa Lam [ 13/Jan/11 10:29 PM ]

Yes, I have the latest workspace.
On Solaris, i am using
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b03)

On Mac, I am using
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-9M3263)

Comment by kumarjayanti [ 13/Jan/11 10:43 PM ]

not sure what is going on. Can you not access the SQE system where everything is setup for you and ready to debug. It is a machine in india though.

Comment by Anissa Lam [ 14/Jan/11 06:24 PM ]

Kumar, thanks.
I am able to setup my env after spending almost the entire day on this trying different setup.

What i find out is that, the following lines doesn't go to the RestAdapter

webResource.addFilter(new HTTPBasicAuthFilter(username, password));
ClientResponse resp = webResource.accept(RESPONSE_TYPE).post(ClientResponse.class);
RestResponse restResp = RestResponse.getRestResponse(resp);

Supposedly, it should reach RestAdapter to do the authentication, but that never happens.
We just get back a response with status 302.

I am not sure who should look into this ? Grizzly team ? or whoever familiar with Jersey Client to take over ?

Comment by kumarjayanti [ 14/Jan/11 07:29 PM ]

right, it appears to me the HTTPBasicAuthFilter never got called. Where is the code for HTTPBasicAuthFilter ?. is it in Jersey ?.

It may be worthwhile to consult jersey folks at this point.

Comment by Tim Quinn [ 14/Jan/11 09:26 PM ]

Status code 302 is for redirection, which would be expected if secure admin is enabled and if the REST connection is using http (as opposed to https). In that case the Grizzly config on the DAS will redirect http to https.

The Java SE classes to not allow automatic redirection-following from http to https; the client needs to handle it explicitly. I do not know what happens within Jersey.

Mitesh might know more; he might have dealt with similar issues with the REST monitoring work.

Comment by Anissa Lam [ 15/Jan/11 08:07 AM ]

This issue only occurs when upgrading from 2.1 Enterprise Profile (which is using NSS) to 3.1.
We have no issue setting secure admin in 3.1, or upgrade from 2.1 Developer/Cluster Profile. Maybe some component isn't handling the upgrade correctly ?

Comment by kumarjayanti [ 16/Jan/11 02:10 AM ]

If you want to know what is different between upgrading from 2.1 to 3.1 Vs setting secure admin in 3.1, then the first thing that is different is that the admin-realm in V2.1EE does not have the user admin with empty password. Instead the password is adminadmin

And when debugging i saw that the AdminConsoleAuthModule is being repeatedly invoked to handle isAnonymousUserEnabled or something like that. I believe the stateless nature of the new Admin-GUI/RestInterface is causing this command to be executed again and again before the login-page appears. As an aside i feel this complete stateless nature can cause performance problems since we are going to the backend again and again for something that can be cached after a first query.

Comment by Anissa Lam [ 16/Jan/11 08:23 AM ]

>> the first thing that is different is that the admin-realm in V2.1EE does not have the user admin with empty password. Instead the password is adminadmin

Understand. However, 2.1 Cluster Profile also has 'adminadmin' as the password but has NO issue after the upgrade. Only the Enterprise Profile which was using NSS before has the problem.

Even though we keep making request repeatedly to REST, we have an authentication token which REST gave to us upon first authentication. This is unavoidable, and i don't see performance hit upon each page refresh due to this.

Comment by Anissa Lam [ 18/Jan/11 05:13 PM ]

In domain.xml, we have a property restAuthURL under <message-security-config> that specifies the endpoint.
<property name="restAuthURL" value="http://localhost:${ADMIN_LISTENER_PORT}/management/sessions"></property>

In 3.1, 'enable-secure-admin' change will change the scheme from 'http' to 'https'.
However, during the upgrade process, this sheme change didn't happen, although the upgraded domain has secure-admin enabled.
So, GUI was still using 'http' instead of 'https'. I believe this can be considered a bug in the upgrade code for not changing this.

However, AdminConsoleAuthModule should be more robust, and test that if secure-admin is on, uses 'https' instead.

I am going to fix AdminConsoleAuthModule to test if secure-admin is on, and ensure that we are using https.

Comment by Anissa Lam [ 18/Jan/11 05:35 PM ]

1. How bad is its impact? (Severity)
Very Severe, Console doesn't allow anyone to login.

2. How often does it happen? (Frequency)
Everytime when v2.1 Enterprise Profile is upgraded to 3.1

3. How much effort is required to fix it? (Cost)
The fix is easy, but figuring out the issue takes couple days.

4. What is the risk of fixing it? (Risk)
Risk is min.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
A work around is to edit domain.xml and change the restAuthURL to start with "https" after the upgrade.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

Here is the svn diff

Index: src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java
===================================================================
— src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (revision 44518)
+++ src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (working copy)
@@ -67,6 +67,7 @@
import org.glassfish.admingui.common.util.RestResponse;
import org.jvnet.hk2.component.Habitat;
import com.sun.enterprise.config.serverbeans.Domain;
+import com.sun.enterprise.config.serverbeans.SecureAdmin;
import com.sun.enterprise.security.SecurityServicesUtil;
import org.glassfish.admingui.common.util.RestUtil;

@@ -107,7 +108,7 @@

  • information needed to continue is present.</p>
    */
    public void initialize(MessagePolicy requestPolicy, MessagePolicy responsePolicy, CallbackHandler handler, Map options) throws AuthException {
  • this.handler = handler;
    + this.handler = handler;
    if (options != null) { // Save the REST URL we need to authenticate the user. this.restURL = (String) options.get("restAuthURL"); @@ -128,13 +129,21 @@ + "must be supplied as a property in the provider-config " + "in the domain.xml file!"); }
    + Habitat habitat = SecurityServicesUtil.getInstance().getHabitat();
    if (restURL.contains(TOKEN_ADMIN_LISTENER_PORT)) { - Habitat habitat = SecurityServicesUtil.getInstance().getHabitat(); Domain domain = habitat.getComponent(Domain.class); String port = domain.getServerNamed("server").getConfig().getNetworkConfig().getNetworkListener("admin-listener").getPort(); restURL = restURL.replace(TOKEN_ADMIN_LISTENER_PORT, port); }
  • }
    +
    + //If secure admin is enabled, we need to ensure using https
    + if (! restURL.startsWith("https"))
    Unknown macro: {+ SecureAdmin secureAdmin = habitat.getComponent(SecureAdmin.class);+ if (SecureAdmin.Util.isEnabled(secureAdmin)) { + restURL = restURL.replace("http", "https"); + }+ }

    + }
    }

/**

Comment by Anissa Lam [ 18/Jan/11 09:39 PM ]

Issue resolved.
Ludo reviewed the code and suggested more explicit test instead of testing not starting with "https". I have modified that if test.

Project: glassfish
Repository: svn
Revision: 44585
Author: anilam
Date: 2011-01-19 05:36:30 UTC
Link:

Log Message:
------------
GLASSFISH-15544. Fix the issue where Upgrading from v2 Enterprise Profile to 3.1 results in not being able to login to GUI.
Upgrade process didn't change the restAuthURL property from "http" to "https". AdminConsoleAuthModule now tests if secure-admin is enabled and change the scheme if secure-admin is on.
Approved: Anissa
Reviewer: Ludo

Revisions:
----------
44585

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java

Diffs:
------
Index: trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java
===================================================================
— trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (revision 44584)
+++ trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (revision 44585)
@@ -67,6 +67,7 @@
import org.glassfish.admingui.common.util.RestResponse;
import org.jvnet.hk2.component.Habitat;
import com.sun.enterprise.config.serverbeans.Domain;
+import com.sun.enterprise.config.serverbeans.SecureAdmin;
import com.sun.enterprise.security.SecurityServicesUtil;
import org.glassfish.admingui.common.util.RestUtil;

@@ -107,7 +108,7 @@

  • information needed to continue is present.</p>
    */
    public void initialize(MessagePolicy requestPolicy, MessagePolicy responsePolicy, CallbackHandler handler, Map options) throws AuthException {
  • this.handler = handler;
    + this.handler = handler;
    if (options != null) { // Save the REST URL we need to authenticate the user. this.restURL = (String) options.get("restAuthURL"); @@ -128,13 +129,19 @@ + "must be supplied as a property in the provider-config " + "in the domain.xml file!"); }
    + Habitat habitat = SecurityServicesUtil.getInstance().getHabitat();
    if (restURL.contains(TOKEN_ADMIN_LISTENER_PORT)) { - Habitat habitat = SecurityServicesUtil.getInstance().getHabitat(); Domain domain = habitat.getComponent(Domain.class); String port = domain.getServerNamed("server").getConfig().getNetworkConfig().getNetworkListener("admin-listener").getPort(); restURL = restURL.replace(TOKEN_ADMIN_LISTENER_PORT, port); }
  • }
    +
    + //If secure admin is enabled, we need to ensure using https
    + SecureAdmin secureAdmin = habitat.getComponent(SecureAdmin.class);
    + if (restURL.startsWith("http:") && (SecureAdmin.Util.isEnabled(secureAdmin))) { + restURL = restURL.replace("http:", "https:"); + }
    + }
    }

/**

Comment by Bobby Bissett [ 19/Jan/11 07:01 AM ]

There's just one little detail left, buried in this early comment:
http://java.net/jira/browse/GLASSFISH-15544?focusedCommentId=189847&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_189847

Can you let me know if the post-upgrade instruction here needs to be removed/changed/left alone?
http://wikis.sun.com/display/GlassFish/NSS+upgrade+instructions#NSSupgradeinstructions-ManualStepstobeCarriedoutafterupgrade

Search for '15544' in the wiki page if the above link doesn't take you right to it.

Comment by Anissa Lam [ 19/Jan/11 08:08 AM ]

There are many steps documented in the wiki page in the section 'Manual Steps to be carried out after upgrade'.
I am not sure what is the purpose or consequences after performing all these steps. Not sure if those are intended for other components either.

But as far as GUI is concerned, with today's build that has the fix above, no steps is needed after upgrade in order to launch and access GUI.

Comment by Bobby Bissett [ 19/Jan/11 08:11 AM ]

No, just that one step referenced in my comment (and the step has a reference to this bug as well). Here's the text:

— begin —
1. Start the server and run the following command (note: this may not be needed. Currently issue 15544 is tracking the problem of logging into the admin console):

./asadmin --secure=true create-ssl --type http-listener --certname s1as admin-listener

Make sure that the domain.xml contains the ssl element for the admin-listener under the protocols element.

Make sure client-auth-enabled is false for this element.
— end —

Is this still needed? Doc issue GLASSFISH-15157 depends on that.

Comment by Bobby Bissett [ 19/Jan/11 08:12 AM ]

Reading you last comment better, I think it answers my last comment. I'll remove that part from the wiki page and can add it back if we need it.

Comment by kumarjayanti [ 19/Jan/11 07:55 PM ]

Please remove this step from the wiki because the AdminUpgradeService takes care of automatically creating an SSL Listener once it detects that we are upgrading from a V2.X EE.

Comment by sss150302 [ 20/Jan/11 04:25 AM ]

I have tried the new build B38, and I still can't login to the admin console.
Have attached
1) the output of ./asadmin start-domain --upgrade domain1 as "upgrade-31-b38.log"
2) domain1 server.log as server.b38.log
3) screenshot console-screen-b38.jpg
You can take a look at my setup ejp-156s-46.india ( /space/31/upgrade/glassfish3 )
source /space/31/upgrade/setenv.sh to use jdk1.6.0_23

Bobby, Have you tried the upgrade with B38?

Comment by Bobby Bissett [ 20/Jan/11 06:55 AM ]

No, and I don't know when b38 was built.

Comment by Anissa Lam [ 20/Jan/11 09:39 AM ]

The fix didn't make it to build 38.

According to this page: http://wikis.sun.com/display/GlassFish/3.1BuildSchedule
Build 38 is based on rev# 44543
and as specified in my comment, the rev with my fix is #44585

Project: glassfish
Repository: svn
Revision: 44585
Author: anilam
Date: 2011-01-19 05:36:30 UTC
Link:

So, Sanjay, can you try to verify the fix using latest nightly build ? or build after 1/19 ?
thanks

Comment by sss150302 [ 21/Jan/11 07:37 AM ]

Wow, Finally, the fix is working fine. Kudos to the teamwork!
I have verified it with Latest Nightly Build B39, Dated 20 jan 2011.

However I would not like to see the annoying Bundle exception in felix on the console as ( details log attached)as upgrade-31-b39-nightly-20-jan-2011.log

Error while starting bundle: file:/space/31/upgrade/glassfish3/glassfish/modules/autostart/org.apache.felix.eventadmin.jar: org.osgi.framework.BundleException: Cannot start bundle org.apache.felix.eventadmin [245] because its start level is 1, which is greater than the framework's start level of 0.
org.osgi.framework.BundleException: Cannot start bundle org.apache.felix.eventadmin [245] because its start level is 1, which is greater than the framework's start level of 0.
at org.apache.felix.framework.Felix.startBundle(Felix.java:1690)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1157)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1135)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1128)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:438)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245)
Error while starting bundle: file:/space/31/upgrade/glassfish3/glassfish/modules/autostart/osgi-javaee-base.jar: org.osgi.framework.BundleException: Cannot start bundle org.glassfish.osgi-javaee-base [246] because its start level is 1, which is greater than the framework's start level of 0.
org.osgi.framework.BundleException: Cannot start bundle org.glassfish.osgi-javaee-base [246] because its start level is 1, which is greater than the framework's start level of 0.
at org.apache.felix.framework.Felix.startBundle(Felix.java:1690)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1157)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1135)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1128)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:438)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245)
Error while starting bundle: file:/space/31/upgrade/glassfish3/glassfish/modules/autostart/osgi-cdi.jar: org.osgi.framework.BundleException: Cannot start bundle org.glassfish.osgi-cdi [247] because its start level is 1, which is greater than the framework's start level of 0.
org.osgi.framework.BundleException: Cannot start bundle org.glassfish.osgi-cdi [247] because its start level is 1, which is greater than the framework's start level of 0.
at org.apache.felix.framework.Felix.startBundle(Felix.java:1690)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1157)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1135)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1128)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:438)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245)

Comment by Anissa Lam [ 21/Jan/11 03:59 PM ]

Thanks for verifying. Please file a separate bug regarding the Bundle Exception. thanks.

Comment by Bobby Bissett [ 21/Jan/11 05:39 PM ]

This is already a known issue. See GLASSFISH-15441 and GLASSFISH-15519.

Generated at Wed Apr 16 19:49:41 UTC 2014 using JIRA 4.0.2#472.