JIRA
  1. JIRA
  2. JRA-14604

Add support for Sun Glassfish application server

    Details

    • Type: New Feature New Feature
    • Status: Open (View Workflow)
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Installation
    • Labels:
      None

      Description

      From a customer:

      FYI. There is a group at Sun that has been running Jira on the GlassFish AS for 8 months. Please add the certification of Jira on GlassFish to your roadmap. Because of GlassFish's rising popularity, this certification will increase the attractiveness of the Atlassian software stack.

      1. jira.log
        142 kB
        Michał Lipski
      2. server.log
        523 kB
        Michał Lipski
      3. server.log
        69 kB
        Eric Spiegelberg

        Issue Links

          Activity

          Hide
          Egil Hasting added a comment -

          I am also experiencing the NullPointerException caused by com.atlassian.seraph.filter.BaseLoginFilter.init(). Isnt there any other way around then recompile the source?

          and what is the reason it happends.. incompatibility between app servers?

          trying to run: Jira 4.2.1-b588 on glassfish 3.0.1

          I really want to see jira running on glassfish in the future

          Show
          Egil Hasting added a comment - I am also experiencing the NullPointerException caused by com.atlassian.seraph.filter.BaseLoginFilter.init(). Isnt there any other way around then recompile the source? and what is the reason it happends.. incompatibility between app servers? trying to run: Jira 4.2.1-b588 on glassfish 3.0.1 I really want to see jira running on glassfish in the future
          Hide
          David Bullock added a comment -

          Sadly, if JIRA takes the same view as Confluence CONF-6603 and Crowd CWD-1732, then we'll never see this. Java EE is dead, and it's not Atlassian's responsibility to revive it.

          Show
          David Bullock added a comment - Sadly, if JIRA takes the same view as Confluence CONF-6603 and Crowd CWD-1732 , then we'll never see this. Java EE is dead, and it's not Atlassian's responsibility to revive it.
          Hide
          clay added a comment -

          I'm not sure what that comment is all about. Java EE is not dead. Respectfully, that's a ridiculous statement. Major corporations, like my company, depend upon the features of a standard application server for integration with an enterprise environment; there is more to running enterprise software than CPU and memory. What's needed is from Atlassian is conformance to the standard. If their applications were designed to work with the standard then deployment to any number of containers would be possible.

          Show
          clay added a comment - I'm not sure what that comment is all about. Java EE is not dead. Respectfully, that's a ridiculous statement. Major corporations, like my company, depend upon the features of a standard application server for integration with an enterprise environment; there is more to running enterprise software than CPU and memory. What's needed is from Atlassian is conformance to the standard. If their applications were designed to work with the standard then deployment to any number of containers would be possible.
          Hide
          David Bullock added a comment -

          I think that Atlassian do conform to the standard to the extent that the standard defines. Despite this, variations in behaviour between application-server implementations are sufficiently numerous to make testing an application on all of them difficult. One might say that the Java EE compliance test suites are not rigorous enough, or that Atlassian have been forced to rely on behaviours not addressed in the specification. In any case, the situation of Java EE standardisation appears not to be meeting the needs of Atlassian, who have a significant product(s) on the Java EE stack. What are they to do when their application runs on 3-4 application servers, but not on a fifth?

          Naturally, this comes back on us poor sods who want to deploy Java EE applications in Java EE containers, because dammit, that's the whole point after all. But I hesitate to point the finger at Atlassian, and the company who might have been in a position to act has just been subsumed by a giant that is showing little interest in open specifications.

          IMHO, Java EE has always had a fail when it comes to deployment. I submit that it's fully ludicrous that in order to get Atlassian to run on a generic app-server, one has to extract the WAR, hack up some files, and run a make script! That's a fault of the Java EE specification, not paying adequate attention to the deployment lifecycle. It seems that after EJB 2.0, everyone in their haste to put the knife into JDO (may it rest in peace) and foist EJB 3.0 on the world, forgot about the foundational separation of roles which was the big news of J2EE as far as the enterprises were concerned.

          What to do about it? Say thanks for the API's, code your product for a high-quality app-server that meets your licensing needs, and make customers run the whole box and dice in virtual machine container instead of a Java EE container.

          Java EE is dead.

          Show
          David Bullock added a comment - I think that Atlassian do conform to the standard to the extent that the standard defines. Despite this, variations in behaviour between application-server implementations are sufficiently numerous to make testing an application on all of them difficult. One might say that the Java EE compliance test suites are not rigorous enough, or that Atlassian have been forced to rely on behaviours not addressed in the specification. In any case, the situation of Java EE standardisation appears not to be meeting the needs of Atlassian, who have a significant product(s) on the Java EE stack. What are they to do when their application runs on 3-4 application servers, but not on a fifth? Naturally, this comes back on us poor sods who want to deploy Java EE applications in Java EE containers, because dammit, that's the whole point after all. But I hesitate to point the finger at Atlassian, and the company who might have been in a position to act has just been subsumed by a giant that is showing little interest in open specifications. IMHO, Java EE has always had a fail when it comes to deployment. I submit that it's fully ludicrous that in order to get Atlassian to run on a generic app-server, one has to extract the WAR, hack up some files, and run a make script! That's a fault of the Java EE specification, not paying adequate attention to the deployment lifecycle. It seems that after EJB 2.0, everyone in their haste to put the knife into JDO (may it rest in peace) and foist EJB 3.0 on the world, forgot about the foundational separation of roles which was the big news of J2EE as far as the enterprises were concerned. What to do about it? Say thanks for the API's, code your product for a high-quality app-server that meets your licensing needs, and make customers run the whole box and dice in virtual machine container instead of a Java EE container. Java EE is dead.
          Hide
          clay added a comment -

          I hear you. When you follow the blue print separation of duties – component provider, assembler, deployer, administrator – it works well, but what I've seen is this takes a lot of discipline. It's easy to "hack" out a web-tier service and throw it on Tomcat. It's hard to build components that use JNDI custom resources for configuration, separate the duties of assembly from deployment, with bindings to external corporate resources for things like security and monitoring, and deploy in containers and environments that require more than casual management. If you do, then you have a stable, scalable and manageable service. This is what large enterprises require and why the company I work for will never allow the likes of Tomcat or Jetty. It'll probably be the reason we eventually abandon Atlassian. They seem to be going a direction that'll make their products incompatible with our environment.

          Show
          clay added a comment - I hear you. When you follow the blue print separation of duties – component provider, assembler, deployer, administrator – it works well, but what I've seen is this takes a lot of discipline. It's easy to "hack" out a web-tier service and throw it on Tomcat. It's hard to build components that use JNDI custom resources for configuration, separate the duties of assembly from deployment, with bindings to external corporate resources for things like security and monitoring, and deploy in containers and environments that require more than casual management. If you do, then you have a stable, scalable and manageable service. This is what large enterprises require and why the company I work for will never allow the likes of Tomcat or Jetty. It'll probably be the reason we eventually abandon Atlassian. They seem to be going a direction that'll make their products incompatible with our environment.

            People

            • Assignee:
              Unassigned
              Reporter:
              Roy Krishna [Atlassian]
            • Votes:
              52 Vote for this issue
              Watchers:
              22 Start watching this issue

              Dates

              • Created:
                Updated: