glassfish
  1. glassfish
  2. GLASSFISH-15544

[BLOCKING] Cannot login to GUI after upgraded from v2 applying Glassfish 2.1.1Patch8 Enterprise profile

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1_b35
    • Fix Version/s: 3.1_b39
    • Component/s: admin_gui
    • Labels:
      None
    • Environment:

      Solaris sparc

      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

      1. domain_after_upgrade.xml
        49 kB
        Bobby Bissett
      2. domain_before_upgrade.xml
        58 kB
        Bobby Bissett
      3. server.b38.log
        136 kB
        sss150302
      4. server.log
        184 kB
        sss150302
      5. server-cannotCreatClassLoader.log
        34 kB
        Anissa Lam
      6. upgrade-31-b38.log
        16 kB
        sss150302
      7. upgrade-31-b39-nightly-20-jan-2011.log
        23 kB
        sss150302
      1. adminconsole-auth-module.jpg
        216 kB
      2. console-screen-b38.jpg
        111 kB
      3. upgraded-admin-b35-jdk6u23.png
        73 kB

        Issue Links

          Activity

          Hide
          Anissa Lam added a comment - - edited

          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 ?

          Show
          Anissa Lam added a comment - - edited 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 ?
          Hide
          Bobby Bissett added a comment -

          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.

          Show
          Bobby Bissett added a comment - 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.
          Hide
          Anissa Lam added a comment -

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

          Show
          Anissa Lam added a comment - Can you also see if it makes any difference in regards to GUI before and after applying the patch specified ? thanks
          Hide
          Bobby Bissett added a comment -

          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.

          Show
          Bobby Bissett added a comment - 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.
          Hide
          Bobby Bissett added a comment -

          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.

          Show
          Bobby Bissett added a comment - 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.
          Hide
          Anissa Lam added a comment -

          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

          Show
          Anissa Lam added a comment - 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
          Hide
          sirajg added a comment -

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

          Show
          sirajg added a comment - Also, Bobby, is secure admin enabled in this case?
          Hide
          Bobby Bissett added a comment -

          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.

          Show
          Bobby Bissett added a comment - 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.
          Hide
          Bobby Bissett added a comment -

          Added domain.xml before/after the upgrade.

          Show
          Bobby Bissett added a comment - Added domain.xml before/after the upgrade.
          Hide
          Bobby Bissett added a comment -

          Ok, trying again.

          Show
          Bobby Bissett added a comment - Ok, trying again.
          Hide
          Anissa Lam added a comment -

          >> 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.

          Show
          Anissa Lam added a comment - >> 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.
          Hide
          Bobby Bissett added a comment -

          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.

          Show
          Bobby Bissett added a comment - 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.
          Hide
          Anissa Lam added a comment -

          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.

          Show
          Anissa Lam added a comment - 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.
          Hide
          kumarjayanti added a comment -

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

          Show
          kumarjayanti added a comment - Can someone attach the server.log so i can quickly see what the error is ?.
          Hide
          kumarjayanti added a comment -

          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.

          Show
          kumarjayanti added a comment - 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.
          Hide
          sss150302 added a comment -

          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.
          Show
          sss150302 added a comment - cat domain1/config/keyfile # Copyright 2004 Sun Microsystems, Inc. All rights reserved. SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. # List of users for simple file realm. Empty by default.
          Hide
          kumarjayanti added a comment -

          hi

          i asked to cat admin-keyfile not keyfile.

          please cat the contents of admin-keyfile

          Show
          kumarjayanti added a comment - hi i asked to cat admin-keyfile not keyfile. please cat the contents of admin-keyfile
          Hide
          sss150302 added a comment -

          cat admin-keyfile
          admin;

          {SSHA}

          qetWv1Zn0cWqP59GgnLCh5iW8Jom27XDLKFEKg==;asadmin

          1. Domain User and Password - Do Not Delete Entry Above
          Show
          sss150302 added a comment - cat admin-keyfile admin; {SSHA} qetWv1Zn0cWqP59GgnLCh5iW8Jom27XDLKFEKg==;asadmin Domain User and Password - Do Not Delete Entry Above
          Hide
          kumarjayanti added a comment -

          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.

          Show
          kumarjayanti added a comment - 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.
          Hide
          sss150302 added a comment -

          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/

          Show
          sss150302 added a comment - 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/
          Hide
          kumarjayanti added a comment -

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

          Show
          kumarjayanti added a comment - where is the right java on that test system. I am default java is 1.5
          Hide
          sss150302 added a comment -

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

          Show
          sss150302 added a comment - source /space/31/upgrade/setenv.sh which sets java version to 1.6.0_23
          Hide
          kumarjayanti added a comment -

          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.

          Show
          kumarjayanti added a comment - 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.
          Hide
          kumarjayanti added a comment -

          Debug session showing problem with RestAuthorization

          Show
          kumarjayanti added a comment - Debug session showing problem with RestAuthorization
          Hide
          Anissa Lam added a comment -

          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

          Show
          Anissa Lam added a comment - 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
          Hide
          Bobby Bissett added a comment -

          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.

          Show
          Bobby Bissett added a comment - 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.
          Hide
          Anissa Lam added a comment -

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

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

          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

          Show
          Anissa Lam added a comment - 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
          Hide
          Anissa Lam added a comment - - edited

          comment removed to not cause confusion.

          Show
          Anissa Lam added a comment - - edited comment removed to not cause confusion.
          Hide
          Bobby Bissett added a comment -

          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

          Show
          Bobby Bissett added a comment - 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
          Hide
          Anissa Lam added a comment -

          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.

          Show
          Anissa Lam added a comment - 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.
          Hide
          Anissa Lam added a comment -

          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

          Show
          Anissa Lam added a comment - 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
          Hide
          kumarjayanti added a comment -

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

          Show
          kumarjayanti added a comment - You will need to put the code in ConsoleClassLoader in a doPrivileged block when System.getSecurityManager() returns non-null.
          Hide
          Anissa Lam added a comment -

          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.

          Show
          Anissa Lam added a comment - 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.
          Hide
          kumarjayanti added a comment -

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

          Show
          kumarjayanti added a comment - not sure. It maybe due to the JDK version then. I am assuming you have the latest workspace on the MAC right ?.
          Hide
          Anissa Lam added a comment -

          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)

          Show
          Anissa Lam added a comment - 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)
          Hide
          kumarjayanti added a comment -

          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.

          Show
          kumarjayanti added a comment - 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.
          Hide
          Anissa Lam added a comment -

          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 ?

          Show
          Anissa Lam added a comment - 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 ?
          Hide
          kumarjayanti added a comment -

          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.

          Show
          kumarjayanti added a comment - 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.
          Hide
          Tim Quinn added a comment -

          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.

          Show
          Tim Quinn added a comment - 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.
          Hide
          Anissa Lam added a comment - - edited

          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 ?

          Show
          Anissa Lam added a comment - - edited 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 ?
          Hide
          kumarjayanti added a comment -

          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.

          Show
          kumarjayanti added a comment - 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.
          Hide
          Anissa Lam added a comment -

          >> 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.

          Show
          Anissa Lam added a comment - >> 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.
          Hide
          Anissa Lam added a comment -

          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.

          Show
          Anissa Lam added a comment - 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.
          Hide
          Anissa Lam added a comment -

          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"); + }+ }

            + }
            }

          /**

          Show
          Anissa Lam added a comment - 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"); + }+ } + } } /**
          Hide
          Anissa Lam added a comment -

          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:"); + }

            + }
            }

          /**

          Show
          Anissa Lam added a comment - 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:"); + } + } } /**
          Hide
          Bobby Bissett added a comment -

          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.

          Show
          Bobby Bissett added a comment - 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.
          Hide
          Anissa Lam added a comment -

          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.

          Show
          Anissa Lam added a comment - 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.
          Hide
          Bobby Bissett added a comment -

          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.

          Show
          Bobby Bissett added a comment - 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.
          Hide
          Bobby Bissett added a comment -

          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.

          Show
          Bobby Bissett added a comment - 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.
          Hide
          kumarjayanti added a comment -

          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.

          Show
          kumarjayanti added a comment - 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.
          Hide
          sss150302 added a comment -

          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?

          Show
          sss150302 added a comment - 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?
          Hide
          Bobby Bissett added a comment -

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

          Show
          Bobby Bissett added a comment - No, and I don't know when b38 was built.
          Hide
          Anissa Lam added a comment -

          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

          Show
          Anissa Lam added a comment - 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
          Hide
          sss150302 added a comment - - edited

          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)

          Show
          sss150302 added a comment - - edited 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)
          Hide
          Anissa Lam added a comment -

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

          Show
          Anissa Lam added a comment - Thanks for verifying. Please file a separate bug regarding the Bundle Exception. thanks.
          Hide
          Bobby Bissett added a comment -

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

          Show
          Bobby Bissett added a comment - This is already a known issue. See GLASSFISH-15441 and GLASSFISH-15519 .

            People

            • Assignee:
              Anissa Lam
              Reporter:
              sss150302
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: