此内容没有您所选择的语言版本。

4.3. Direct Access

If no parameters are given to the run.sh script when the client is started, a reference to the HRService bean is looked up using the Microcontainer controller after the service is deployed:

private HRManager manager;
...
private final static String HRSERVICE = "HRService";

...
void deploy() {
    bootstrap.deploy(url);
    if (!useBus && manager == null) {
	ControllerContext context = controller.getInstalledContext(HRSERVICE);
	if (context != null) { manager = (HRManager) context.getTarget(); }
    }
}

private HRManager manager;
...
private final static String HRSERVICE = "HRService";

...
void deploy() {
    bootstrap.deploy(url);
    if (!useBus && manager == null) {
	ControllerContext context = controller.getInstalledContext(HRSERVICE);
	if (context != null) { manager = (HRManager) context.getTarget(); }
    }
}

Copy to Clipboard

Toggle word wrap

Rather than immediately looking up a reference to the bean instance, the example first looks up a reference to a ControllerContext, then obtains a reference to the bean instance from the context using the getTarget() method. The bean can exist within the Microcontainer in any of the states listed in States of a Bean Within the Microcontainer.

States of a Bean Within the Microcontainer

NOT_INSTALLED
DESCRIBED
INSTANTIATED
CONFIGURED
INSTALLED

To keep track of which state the bean is in, wrap it in another object called a context that describes the current state. The name of the context is the same as the bean name. Once a context reaches the INSTALLED state, the bean it represents is considered to be deployed.

After creating a reference to the bean instance representing the service entry point, you can call methods on it to preform work:

@SuppressWarnings("unchecked")
    
    Set<Employee> listEmployees() {
    if (useBus)
	...
    else
	return manager.getEmployees();
}

@SuppressWarnings("unchecked")
    
    Set<Employee> listEmployees() {
    if (useBus)
	...
    else
	return manager.getEmployees();
}

Copy to Clipboard

Toggle word wrap

The client is accessing the service directly since it is using a reference to the actual bean instance. Performance is good, because each method call goes directly to the bean. What happens, however, if you want to reconfigure the service and redeploy it while the application is running?

Reconfiguration is achieved by making changes to the XML deployment descriptor and saving the file. In order to redeploy the service, the current instance must be undeployed. During undeployment the Microcontainer controller releases its reference to the bean instance, along with any dependent beans. These beans will subsequently become available for garbage collection because they are no longer required by the application. Redeploying the service creates new bean instances representing the new configuration. Any subsequent look-ups from clients will retrieve references to these new instances and they will be able to access the reconfigured service.

The problem is that the reference to the bean instance representing our service entry point is cached when you deploy the service for the first time. Undeploying the service has no affect, since the bean instance can still be accessed using the cached reference and it will not be garbage collected until the client releases it. Along the same line, deploying the service again will not cause another look-up because the client already has a cached reference. It will therefore continue to use the bean instance representing the initial service configuration.

You can test this behavior by typing u followed by RETURN to undeploy the current service. You should still be able to access the service from the client even though it is 'undeployed'. Next, make some changes to the configuration using the jboss-beans.xml file, save the file, and deploy it again using the d option. Printing out the status of the service using the p option shows that the client is still accessing the initial instance of the service that was deployed.

Warning

Even if you modify the client to look up a new reference each time the service is redeployed, new developers may hand out copies of this reference to other objects, by mistake. If all of these references are not cleaned up during redeployment, the same caching problem can occur.

To reliably redeploy the reconfigured service, shut down the application completely using the 'q' option and restart it again using the run.sh script. For enterprise services such as Transactions, Messaging and Persistence this is perfectly acceptable behavior, since they are generally always in use. They cannot be redeployed at run-time and also benefit from the high performance given by using direct access. If your service falls into this category, consider using direct access via the Microcontainer controller.

此内容没有您所选择的语言版本。

4.3. Direct Access

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links