Dependency in JavaEE-dependency search and javaee dependency

Dependency in JavaEE-dependency search and javaee dependency

The first rule about dependency management is dependency lookup ). This policy is a traditional form of dependency management in JavaEE. Here we can see the JNDI (Java Naming andDirectoryInterface) in the JavaEE specification. From the name, we can see that the solution to dependency is through searching.

As mentioned in the previous article, the resource to be referenced is identified by a pair of annotations corresponding to name and target. Name indicates the name of the resource when the resource is dependent. Therefore, when the resource annotation is placed on the class definition, You need to name it. However, if the resource annotation is placed on a field or a setter method, you do not need to name it. In general, when dependency search is used, annotations are placed on classes and explicitly specified names. The next blog will discuss how to place annotations in a field or setter method.

The role of the specified name is to facilitate the caller's dynamic resolution reference. Because JNDI is the specification of JavaEE, all JavaEE application servers support JNDI, and each component has its own local range of JNDI naming context, which is called the environment naming context. When a resource is searched through JNDI, It is searched according to the predefined name in the context of its environment naming. The following code masks how to use dependency lookup to serve an EJB component.

@Stateless@EJB(name="audit", beanInterface=AuditService.class)public class DepartmentServiceBean implements DepartmentService {    private AuditService audit;        @PostConstruct    public void init() {        try {            Context ctx = new InitialContext();            audit = (AuditService) ctx.lookup("java:comp/env/audit");        } catch (NamingException e) {            throw new EJBException(e);        }    }    public void performAudit() {        audit.audit();    }        // ...}

We can see that DeptServiceBean is a session bean. It uses the @ EJB annotation to declare the dependencies of a session bean and name it "audit ". @ The beanInterface element of the EJB annotation references the business interface (AuditService) required in the Session bean ). Find and obtain the corresponding resources in the init method. The Context and IitialContext interfaces are all defined by JNDI. The lookup () method of the Context interface is the main method used to retrieve objects from the JNDI Context. To locate the reference named "audit", the application searches for the name "java: comp/env/audit" and converts the result to the AuditService business interface. The prefix "java: comp/env" added to the reference name indicates that the server should use the environment name to search for and discover references. If an incorrect name is specified, an exception is thrown when the query fails.

This method of JNDI solves the dependency problem is common. as long as it complies with the JavaEE standard, you can use this search method to find the interface you are concerned about (in fact, the final work is to implement) however, this method of searching for resources is cumbersome, similar to buying fire-fighting equipment when the house is on fire (why not buy it in advance? This is what we will talk about in the next blog ).

In addition to the lookup method of the Context interface in the code above, EJB can also use the lookup method of the EJBContext interface (and its sub-interface. In this way, you can access the service (timing service?) when the program is running ?) The following code demonstrates this lookup method.

@Stateless@EJB(name="audit310", beanInterface=AuditService310.class)public class DepartmentServiceBean310 implements DepartmentService310 {    // use of resource dependency injection is covered later in the chapter    @Resource SessionContext context;    AuditService310 audit;    public void setSessionContext(SessionContext context) {        this.context = context;    }        @PostConstruct    public void init() {        audit = (AuditService310) context.lookup("audit310");    }    public void performAudit() {        audit.audit();    }        // ...}

Although many people on the Internet say that the EJBContext lookup () method has advantages over JNDIAPI. First, the parameter of the method happens to be the name specified in the resource reference. You do not need to write any strange strings in the first part of the code. The second is about Exception Handling. Obviously, the second method does not need to be manually handled, because the second method directly throws a runtime exception. In fact, the container still calls the jndi api like the first method, but it is easy to handle exceptions for us, this makes the second method seem to have no need to deal with the above. In my opinion, these two methods are not the most suitable method for us. Just like the example above, I want to buy fire-fighting equipment only when I am on fire. Why don't I buy them in advance? This is another policy that we will introduce in the next blog to resolve dependencies-dependency injection.