Now let’s look at the bean’s runtime environment

We’re almost done with the bean’s world. Now that we’ve seen the bean’sspecial JNDI environment, we still have a few more little details on the bean’s runtime environment. Each of these is covered by the exam objectives, so don’t fall asleep now. We’re almost done!

  • Guaranteed APIs

    You must which APIs are and are not guaranteed to be part of every EJB 2.0 container. For example, JMS is supported, JXTA is not.

  • Guaranteed services

    You must know what is and is not guaranteed to be supported by every EJB 2.0 container. For example, transaction support is guaranteed, load-balancing is not.

  • Structure of the ejb-jar

    Maybe this isn’t really a runtime environment thing, but we didn’t have another good place to stick it, and you have to know it. So here it is, just in case you don’t remember what we covered waaaaay back in Chapter 1. For example, you must know that the an ejb-jar does not have a manifest, but MUST have a META-INF directory, and that directory MUST hold the deployment descriptor. Which, oh yes, MUST be named “ejb-jar.xml”.

  • Programming restrictions

    If you want your bean to be portable to / compatible with any EJB 2.0-compliant container, you must not do any of the things on the list, even if your vendor allows it (which the vendor may do unintentionally).

    And it’s not just for portability, but for safety. If you try to manage your own threads, for example, you’re stepping on the Container’s toes, and who knows what kind of mess you’ll ...

Get Head First EJB now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.