Discussions

News: JSR 88: J2EE Deployment API Proposed Final Draft

Bookmark and Share Get thread feed

  1. JSR 88: J2EE Deployment API Proposed Final Draft (17 messages)

    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.
    Reply to this

    Threaded Messages (17)

  2. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    This is great! I think it will make everyone's ant scripts much cleaner :) :)
    Reply to this Reply to original

  3. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    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!
    Reply to this Reply to original

  4. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    Whats to it? You just copy the .ear file to the deploy directory and your done. You need an api for this?

    jboss.org
    Reply to this Reply to original

  5. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    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.
    Reply to this Reply to original

  6. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    How many people deploy apps to servers in their garage anyway? :) Doesn't sound like a reliable hosting solution.
    Reply to this Reply to original

  7. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    My garage started looking pretty good after what we had to go through to get out of Exodus!
    Reply to this Reply to original

  8. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    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 ?
    Reply to this Reply to original

  9. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    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...
    Reply to this Reply to original

  10. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    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
    Reply to this Reply to original

  11. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    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.
    Reply to this Reply to original

  12. EAR files just define packaing standard not deployment[ Go to top ]

    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.

    Reply to this Reply to original

  13. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    jboss.org? haha!
    We are using weblogic.
    Reply to this Reply to original

  14. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

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

    Reply to this Reply to original

  15. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    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
    Reply to this Reply to original

  16. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    ..., 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...
    Reply to this Reply to original

  17. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    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.
    Reply to this Reply to original

  18. JSR 88: J2EE Deployment API Proposed Final Draft[ Go to top ]

    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.
    Reply to this Reply to original