Discussions

News: JSR 88: J2EE Deployment API Proposed Final Draft

  1. JSR 88, the J2EE Deployment API Specification Proposed Final Draft is available for download. JSR 88 describes an open standard for deploying J2EE applications to a J2EE platform. This API allows any tool to deploy J2EE applications to any J2EE platform.

    Download the J2EE Deployment API PFD.

    Check out JSR 88.

    Threaded Messages (17)

  2. This is great! I think it will make everyone's ant scripts much cleaner :) :)
  3. I wish Sun would just put their documentation "online" on the web instead of requiring you to download it - for starters, it would get spidered in search engines, as well as saving my time, bandwidth and hard drive space.

    Still, I think a deployment API is long overdue. Hurrah!
  4. Whats to it? You just copy the .ear file to the deploy directory and your done. You need an api for this?

    jboss.org
  5. If you are using a cluster manageble, enterprise wide solution to support hundreds or thousands of users, yes. If you are deploying a program in your garage, then no. When it comes to platform deployment, the API is LONG overdue. The true question will be if and when application server vendors adopt it. Currently I have been, and still am, fighting with Borland Enterprise Server for over a week to get my deployment converted from Appserver 4.5. If this API was in place, I'd have spent last week working on logic code for my company.
  6. How many people deploy apps to servers in their garage anyway? :) Doesn't sound like a reliable hosting solution.
  7. My garage started looking pretty good after what we had to go through to get out of Exodus!
  8. Well why would you need the API if that is the case(lots of users and clustering?) I did not get that? Isn't a ".ear" file okay ?
  9. The reason you need a deployment API in a clustered environment is that you have to guarantee that all members of a cluster receive the update at the same time or no members receive it. Otherwise you will get strange behavior in some situations...
  10. How long will it be before the app server vendors really follow this proposed final draft? App server vendors will have a tough time maintaing their client base if the appserver is not meeting to customers requirements.. Customers might move over to a differnt appserver with just few clicks ...

    Raj
  11. App server vendors will have a tough time maintaing their

    > client base if the appserver is not meeting to customers
    > requirements.. Customers might move over to a differnt
    > appserver with just few clicks ...
    I would not state it that way. Look it from the other side: for a good app server, new customers come in with just a few clicks.
  12. I don't think the target audience here is the developers or deployers. The target here is App Servers and deployment tool providers. EAR files just define the packaging. What you do with the EAR file is what is different.

    For WLS, you have put the EAR in the application directory and put to a target server, where the deployed code is then generated.

    For WebSphere, you need to generate the deployed code through WSAD or AAT and then install the application to a server.

    With JSR 88, IDE's can use the same code or wizard to deploy to different App Servers instead of having to create a different wizard for each application server the IDE plans to support.

  13. jboss.org? haha!
    We are using weblogic.
  14. I don't know if I'm missing the point here :

    Is the aim of this JSR to make it possible for Appserver vendors to use a standard way to deploy J2EE application on their platforms??

    Porting EJBs hasn't exactly been a breeze between different vendors products because of different vendor specific container descriptors, and a quick browse through the JSR didn't give me much on that issue. DISAPPOINTED!!!

    Why don't they just standardise the vendor-specific deployment descriptor files (XML, DTDs) for the container specific descriptors. That would make deployment easy on any platform without a new API to learn!

    Just my two cents.....

  15. Hi,

    I haven't read JSR88 yet, but from the headlines, I understand that the API itself, gives yoú the abstraction to build your deployment procedures independently from the ApplicationServer.
    Also I think some part of the APIs are ment to be adopted by the AppServer Vendors.
    This way it will act as a glue between the different J2EE deployment Roles.

    Regards
    Jannik
  16. ..., and a quick browse through the JSR didn't give me

    > much on that issue. DISAPPOINTED!!!
    > Why don't they just standardise the vendor-specific
    > deployment descriptor files (XML, DTDs) for the container
    > specific descriptors. That would make deployment easy on
    > any platform without a new API to learn!
    I haven't read the JSR yet, but if you're right, I'm very disappointed too, for exactly the same reason as you.
    In fact, when I read the title of this thread, I thought that the vendor-specific deployment descriptor files where _finally_ made optional.

    Maybe I'm hoping too much...
  17. Application Server vendors differentiate their products in Quality of Service features (performance, scalability, load balancing, failover, etc...) and often use proprietary descriptors to convey this value-add information as part of a shipped application. This is certainly the case now where different Vendor CMP implementations use proprietary descriptor definitions for specifying tuning & caching parameters (which are not standardised by specs).
    So, on the assumption that proprietary descriptors will consitute part of an .ear, I can't see how JSR88 will define a universal deployment API.
  18. I think this aspect needed standardising. Tool vendors only have one 'package' to implement. However it's more of a burden on J2EE server implementors, who are already playing catch up, and will need to rewrite a great deal of their code.

    Unfortunately the standard does not address design-time deployment, migration or failover. It appears on first reading that putting this standard in place could act as a limitation on implementing these features.

    Also the conformity seems to place yet more 'red-tape' on the application programmer. I would have liked to have seen an example of how to deploy a jar by simply placing it in a directory.