JSR-88: J2EE Deployment API class binaries now available


News: JSR-88: J2EE Deployment API class binaries now available

  1. JSR-88 (J2EE Deployment API) class binaries are now publicly available. JSR-88 describes an open standard for deploying J2EE applications to a J2EE platform. These class binaries will form the underlying mechanism for which tool vendors and J2EE Compliant AppServers of the future will use to enable deployment.

    JSR-88 class binaries are now publicly available. It can be downloaded from http://java.sun.com/j2ee/tools/deployment

    You can use these class files to write config beans that would be supported by the next generation of tools without having to do a rewrite later.

    You can send your comments to the JSR-88 expert group by sending a message to [email protected]

    Threaded Messages (8)

  2. This API's success will be judged on the support that it gets from both the tool vendor side, and the app server vendor side.

    The idea of a nice generic <j2eedeploy ... /> ant task
    that can deploy to any app server sounds good to me!
  3. Actually, I've been looking into this spec and I don't think it will provide the facilities for a generic ant task. It is better suited toward GUI tools that present a user interface. That way it works is the tool requests beans from the server that dynamically expose the deployment features of the server. You then use a PropertyEditor to display these to the user... So, the key value pairs will still differ among J2EE server vendors. In other words, it appears that you're out of luck with Ant.
  4. JSR-88: Ant[ Go to top ]

        A solution like Ant would implicitly assume that you know how to specify and package all the deployment information for your app server. (For example, stuff server-specific XML deployment descriptors in an EJB JAR or WAR.) JSR-88 cannot make that assumption, since there is no requirement that app server vendors support that sort of packaging. For example, in some products, the deployment tools send information directly to a database that the app server communicates with, rather than storing XML files in a JAR.
        Given that, the spec must assume that the user needs to interact with the beans in order to specify their deployment information to the server. That would seem to leave Ant right out of the picture.
        However, there will still be some vendors that support XML files as their preferred format for deployment information. The API call to deploy a bean passes a "deployment plan" of unspecified format to the server, where that "deployment plan" was generated by the configuration beans. If you happen to know the format of the deployment plan for a particular server, there's nothing to prevent you from writing an Ant task to submit an XML file stored on your disk somewhere as the deployment plan, pretending that it came from the configuration beans. That would, of course, still be a server-specific solution.
        You can make the argument that all vendors should be required to support the same format for deployment information, and if that's how you feel, send it to the expert group. I think your odds of convincing the J2EE spec lead and/or all the vendors to accomodate you are slim, however.

  5. JSR-88: Ant[ Go to top ]

    One more thought:
        Your GUI tool can save the deployment plan to disk (the API calls to do that are included in JSR-88), and the configuration beans can load it from disk (also within the JSR-88 API). It would be possible to run through the paces in a tool and the save the deployment plan to disk. Then you could create an Ant task which loaded the config beans from the server, had them import the saved plan from disk, and deployed on that basis. That would be portable across servers. It may be a little onerous to manually generate the deployment plan in a tool that complies with JSR-88, but hey, you've got to generate your deployment information somehow.
  6. JSR-88:Ant[ Go to top ]

    oops i dont know whether i would get a reply for this grandfather of a post. doesnt the deploymentplan which can be send as an inputStream from the client to DeploymentService have to comply with any interface ?as you have said ,people can use that as a workaround.but is the intention of the api is to support that workaround ? iam not able to understand why the distribute apis(present in DeploymentManager) doesnt specify any standard interfaces,which can be serializable objects . one thing i have come to understand ,jsr-88 seems to be solving a different purpose from what we perceived?no more appserver specific deployment description,if you stick to standard artifacts and deployment configuration. the single most requirment and an absentee ,JNDI description. other than JNDI description,i would not use anything server specific and if there is a way i can transparently provide that information,i would be content with providing an archive which has standard information alone and nothing else. regards, jana
  7. The sad thing is that this deployment spec only really looks at deployment as a first-time effort. The components and what not for redeployment are "optional". <sarcasm> This, of course, makes operations people really happy</sarcasm>.
  8. JSR-88: Redeploy[ Go to top ]

        Redeploy is not required for two reasons: 1) it seems onerous to force all vendors to implement it, though in practice most do, and 2) it turned out to be extremely hard to agree on a definition. For one thing, it's difficult to nail down exactly what's allowed to change in a redeploy. Probably remote interfaces shouldn't change, possibly not local interfaces, but are you sure? And how do the clients get updated? Are external clients treated differently than clients in the same app or clients in a J2EE client container?
        Then we have the app server issue: high-end products may take the "administrator" approach and guarantee that all existing work is completed against the old code, while new connections are handled by the new code, all across a cluster, with transactional support of the redeploy (if one component somewhere fails, the redeploy is canceled across the entire cluster). Low-end products may take the "developer" approach and just mangle existing clients in favor of getting the new code in there ASAP, and if it doesn't work, oh well, restart.
        It's not clear that one of the approaches is right and the other wrong. Certainly we'd like every product to take the high-end approach, but it doesn't seem reasonable to require it. And in any case, you might imagine that a vendor whose product supports redeploy will certainly implement that part of the spec as a differenting factor, so I wouldn't worry abut it.
        But in any case, if you feel strongly, well, send your thoughts (and recommendations) to the expert group.
  9. JMX?[ Go to top ]

    How is JSR-88 related to JMX and MBeans?