Details

    • Type: Sub-task Sub-task
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.0_b71
    • Component/s: admin
    • Labels:
      None

      Activity

      Hide
      tvlatas added a comment -

      I grabbed the changes that were listed for removing the DiagnosticService from the templates and reproduced the admin dev test failures here.

      I took a look and the problem with the changes is that there apparently is also a org.glassfish.config.support.DefaultConfigUpgrade.postConstruct() which relies on both the order and existence of elements in the domain templates.

      When I removed the createDiagnosticServiceConfig(defaultConfig); from the postConstruct() these tests passed.

      I'm not familiar with that code, so I don't know if removing that call will have other side effects, so I may find other issues as I test this out.

      Show
      tvlatas added a comment - I grabbed the changes that were listed for removing the DiagnosticService from the templates and reproduced the admin dev test failures here. I took a look and the problem with the changes is that there apparently is also a org.glassfish.config.support.DefaultConfigUpgrade.postConstruct() which relies on both the order and existence of elements in the domain templates. When I removed the createDiagnosticServiceConfig(defaultConfig); from the postConstruct() these tests passed. I'm not familiar with that code, so I don't know if removing that call will have other side effects, so I may find other issues as I test this out.
      Hide
      tvlatas added a comment -

      quick update on the testing.

      The admin dev tests for upgrade are failing for me with the above mentioned change I made, but they appear to be unrelated to my change and looks more like those tests don't run properly on JDK 7:

      [java] Exception in thread "main" MultiException stack 1 of 2
      [java] java.lang.UnsupportedClassVersionError: com/sun/enterprise/admin/cli/optional/BackupDomainCommand : Unsupported major.minor version 51.0
      [java] at java.lang.ClassLoader.defineClass1(Native Method)
      [java] at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
      [java] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
      [java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)

      Show
      tvlatas added a comment - quick update on the testing. The admin dev tests for upgrade are failing for me with the above mentioned change I made, but they appear to be unrelated to my change and looks more like those tests don't run properly on JDK 7: [java] Exception in thread "main" MultiException stack 1 of 2 [java] java.lang.UnsupportedClassVersionError: com/sun/enterprise/admin/cli/optional/BackupDomainCommand : Unsupported major.minor version 51.0 [java] at java.lang.ClassLoader.defineClass1(Native Method) [java] at java.lang.ClassLoader.defineClass(ClassLoader.java:634) [java] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) [java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
      Hide
      tvlatas added a comment -

      Found the problem the issue was that while the JAVA_HOME was set, the PATH was still finding an older version of the JDK (so thus the mismatch).

      Setting the path to the JDK 1.7 and rerunning the tests passed.

      I'm going to rerun the full set locally, but it looks like this change should be OL.

      Show
      tvlatas added a comment - Found the problem the issue was that while the JAVA_HOME was set, the PATH was still finding an older version of the JDK (so thus the mismatch). Setting the path to the JDK 1.7 and rerunning the tests passed. I'm going to rerun the full set locally, but it looks like this change should be OL.
      Hide
      tvlatas added a comment -

      Revision 58967 was committed to address this

      Show
      tvlatas added a comment - Revision 58967 was committed to address this
      Hide
      tvlatas added a comment -

      In reviewing the one-pager for config modularity, I believe that the original set of changes the config team had listed to resolve this on their wiki was insufficient. It only addressed the domain defaults.

      The DiagnosticService configuration allows extensions, and the pattern for that is changing, so we also need to review and update to align with the new pattern/annotations there now as well.

      Show
      tvlatas added a comment - In reviewing the one-pager for config modularity, I believe that the original set of changes the config team had listed to resolve this on their wiki was insufficient. It only addressed the domain defaults. The DiagnosticService configuration allows extensions, and the pattern for that is changing, so we also need to review and update to align with the new pattern/annotations there now as well.

        People

        • Assignee:
          tvlatas
          Reporter:
          Masoud Kalali
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated: