[CONF] Apache Tapestry Tapestry Inversion of Control Container
Tapestry Inversion of Control Container Page added by Bob Harner This page has moved to Tapestry Inversion of Control FAQ Change Notification Preferences View Online
[CONF] Apache Tapestry Tapestry Inversion of Control Container
Tapestry Inversion of Control Container
Page edited by Howard M. Lewis Ship
Changes (1)
...
public void startupService(RegistryShutdownHub shutdownHub) {
shutdownHub.addRegistryShutdownListener(this);
}
...
Full Content
Tapestry Inversion of Control Container
Main article: Tapestry IoC
Why do I need to define an interface for my services? Why can't I just use the class itself?
First of all: you can do exactly this, but you lose some of the functionality that Tapestry's IoC container provides.
The reason for the split is so that Tapestry can provide functionality for your service around the core service implementation. It does this by creating proxies: Java classes that implement the service interface. The methods of the proxy will ultimately invoke the methods of your service implementation.
One of the primary purposes for proxies is to encapsulate the service's life cycle: most services are singletons that are created just in time. Just in time means only as soon as you invoke a method. What's going on is that the life cycle proxy (the object that gets injected into pages, components or other service implementations) checks on each method invocation to see if the actual service exists yet. If not, it instantiates and configures it (using proper locking to ensure thread safety), then delegates the method invocation to the service.
If you bind a service class (not a service interface and class), then the service is fully instantiated the first time it is injected, rather than at that first method invocation. Further, you can't use decorations or method advice on such a service.
The final reason for the service interface / implementation split is to nudge you towards always coding to an interface, which has manifest benefits for code structure, robustness, and testability.
My service starts a thread; how do I know when the application is shutting down, to stop that thread?
This same concern applies to any long-lived resource (a thread, a database connection, a JMS queue connection) that a service may hold onto. Your code needs to know when the application has been undeployed and shutdown. This is actually quite easy, by adding some post-injection logic to your implementation class.
public class MyServiceImpl implements MyService, RegistryShutdownListener
{
private boolean shuttingDown;
private final Thread workerThread;
public MyServiceImpl()
{
workerThread = new Thread(. . .);
}
. . .
@PostInjection
public void startupService(RegistryShutdownHub shutdownHub)
{
shutdownHub.addRegistryShutdownListener(this);
}
public void registryDidShutdown()
{
shuttingDown = true;
workerThread.interrupt();
}
}
After Tapestry invokes the constructor of the service implementation, and after it performs any field injections, it invokes post injection methods. The methods must be public and return void. Parameters to a post injection method represent further injections ... in the above example, the RegistryShutdownHub is injected into the PostInjection method, since it is only used inside that one method.
It is not recommended that MyServiceImpl take RegistryShutdownHub as a constructor parameter and register itself as a listener inside the constructor. Doing so is an example of unsafe publishing, a remote but potential thread safety issue.
This same technique will work for any kind of resource that must be cleaned up or destroyed when the registry shuts down.
Be careful not to invoke methods on any service proxy objects as they will also be shutting down with the Registry. A RegistryShutdownListener should not be reliant on anything outside of itself.
Change Notification Preferences
View Online
|
View Changes
[CONF] Apache Tapestry Tapestry Inversion of Control Container
Tapestry Inversion of Control Container
Page edited by Howard M. Lewis Ship
Changes (25)
...
h3. My service starts a thread; how do I know when the application is shutting down, to stop that thread?
This same concern applies to any long-lived resource (a thread, a database connection, a JMS queue connection) that a service may hold onto. Your code needs to know when the application has been undeployed and shutdown. This is actually quite easy, by using a service builder method. In adding some post-injection logic to your module class: implementation class.
{code:controls=true|linenumbers=true}
public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub)
public class MyServiceImpl implements MyService, RegistryShutdownListener
{
final MyServiceImpl service = resources.autobuild(MyServiceImpl.class);
private boolean shuttingDown;
shutdownHub.addRegistryShutdownListener(new RegistryShutdownListener() { public void registryDidShutdown() { service.shutdown(); } });
private final Thread workerThread;
return service;
public MyServiceImpl() { workerThread = new Thread(. . .);
}
{code}
This code uses the ServiceResources object to build an instance of MyServiceImpl, with all dependencies injected. It also injects Tapestrys RegistryShutdownHub service and adds a listener. The example assumes that the service implementation (but not the service _interface_) includes a {{shutdown()}} method.
. . .
A valid alternative to this would be to have MyServiceImpl implement RegistryShutdownListener:
@PostInjection public void startupService(RegistryShutdownHub shutdownHub) { shutdownHub.addShutdownListener(this); }
{code:controls=true|linenumbers=true} public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub)
public void registryDidShutdown()
{
final MyServiceImpl service = resources.autobuild(MyServiceImpl.class);
shuttingDown = true;
shutdownHub.addRegistryShutdownListener(service); workerThread.interrupt();
}
return service;
}
{code}
After Tapestry invokes the constructor of the service implementation, and after it performs any field injections, it invokes post injection methods. The methods must be public and return void. Parameters to a post injection method represent further injections ... in the above example, the RegistryShutdownHub is injected into the PostInjection method, since it is only used inside that one method.
{warning}
It is *not* recommended that MyServiceImpl take RegistryShutdownHub as a constructor parameter and register itself as a listener. Doing so is an example of [unsafe publishing|http://www.ibm.com/developerworks/java/library/j-jtp0618.html].
It is *not* recommended that MyServiceImpl take RegistryShutdownHub as a constructor parameter and register itself as a listener inside the constructor. Doing so is an example of [unsafe publishing|http://www.ibm.com/developerworks/java/library/j-jtp0618.html], a remote but potential thread safety issue.
{warning}
This same technique will work for any kind of resource that must be cleaned up or destroyed when the registry shuts down. {note} Be careful not to invoke methods on any service proxy objects as they will also be shutting down with the Registry. A RegistryShutdownListener should not be reliant on anything outside of itself. {note}
Full Content
Tapestry Inversion of Control Container
Main article: Tapestry IoC
Why do I need to define an interface for my services? Why can't I just use the class itself?
First of all: you can do exactly this, but you lose some of the functionality that Tapestry's IoC container provides.
The reason for the split is so that Tapestry can provide functionality for your service around the core service implementation. It does this by creating proxies: Java classes that implement the service interface. The methods of the proxy will ultimately invoke the methods of your service implementation.
One of the primary purposes for proxies is to encapsulate the service's life cycle: most services are singletons that are created just in time. Just in time means only as soon as you invoke a method. What's going on is that the life cycle proxy (the
[CONF] Apache Tapestry Tapestry Inversion of Control Container
Tapestry Inversion of Control Container
Page edited by Bob Harner
Changes (1)
h2. Tapestry Inversion of Control Container
Main article: [Tapestry IoC|IoC]
h3. Why do I need to define an interface for my services? Why cant I just use the class itself?
...
Full Content
Tapestry Inversion of Control Container
Main article: Tapestry IoC
Why do I need to define an interface for my services? Why can't I just use the class itself?
First of all: you can do exactly this, but you lose some of the functionality that Tapestry's IoC container provides.
The reason for the split is so that Tapestry can provide functionality for your service around the core service implementation. It does this by creating proxies: Java classes
that implement the service interface. The methods of the proxy will ultimately invoke the methods of your service implementation.
One of the primary purposes for proxies is to encapsulate the service's lifecycle: most services are singletons that are created just in time. Just in time means only as soon
as you invoke a method. What's going on is that the lifecycle proxy (the object that gets injected into pages, components or other service implementations) checks on each method invocation
to see if the actual service exists yet. If not, it instantiates and configures it (using proper locking to ensure thread safety), then delegates the method invocation to the service.
If you bind a service class (not a service interface and class), then the service is fully instantiated the first time it is injected, rather than at that first method invocation. Further, you
can't use decorations or method advice on such a service.
The final reason for the service interface / implementation split is to nudge you towards always coding to an interface, which has manifest benefits for code structure, robustness, and testability.
My service starts a thread; how do I know when the application is shutting down, to stop that thread?
This same concern applies to any long-lived resource (a thread, a database connection, a JMS queue connection) that a service may
hold onto. Your code needs to know when the application has been undeployed and shutdown. This is actually quite easy, by using
a service builder method. In your module class:
public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub)
{
final MyServiceImpl service = resources.autobuild(MyServiceImpl.class);
shutdownHub.addRegistryShutdownListener(new RegistryShutdownListener()
{
public void registryDidShutdown()
{
service.shutdown();
}
});
return service;
}
This code uses the ServiceResources object to build an instance of MyServiceImpl, with all dependencies injected.
It also injects Tapestry's RegistryShutdownHub service and adds a listener. The example assumes that the service implementation
(but not the service interface) includes a shutdown() method.
A valid alternative to this would be to have MyServiceImpl implement RegistryShutdownListener:
public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub)
{
final MyServiceImpl service = resources.autobuild(MyServiceImpl.class);
shutdownHub.addRegistryShutdownListener(service);
return service;
}
It is not recommended that MyServiceImpl take RegistryShutdownHub as a constructor parameter and register itself as a listener Doing so is an example of unsafe publishing.
Change Notification Preferences
View Online
|
View Changes
[CONF] Apache Tapestry Tapestry Inversion of Control Container
Tapestry Inversion of Control Container
Page edited by Howard M. Lewis Ship
Changes (4)
...
a service builder method. In your module class:
{newcode:controls=true|linenumbers=true}
public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub) {
...
return service; }
{newcode}
This code uses the ServiceResources object to build an instance of MyServiceImpl, with all dependencies injected.
...
A valid alternative to this would be to have MyServiceImpl implement RegistryShutdownListener:
{newcode:controls=true|linenumbers=true}
public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub) {
...
return service; }
{newcode}
{warning}
...
Full Content
Tapestry Inversion of Control Container
Why do I need to define an interface for my services? Why can't I just use the class itself?
First of all: you can do exactly this, but you lose some of the functionality that Tapestry's IoC container provides.
The reason for the split is so that Tapestry can provide functionality for your service around the core service implementation. It does this by creating proxies: Java classes
that implement the service interface. The methods of the proxy will ultimately invoke the methods of your service implementation.
One of the primary purposes for proxies is to encapsulate the service's lifecycle: most services are singletons that are created just in time. Just in time means only as soon
as you invoke a method. What's going on is that the lifecycle proxy (the object that gets injected into pages, components or other service implementations) checks on each method invocation
to see if the actual service exists yet. If not, it instantiates and configures it (using proper locking to ensure thread safety), then delegates the method invocation to the service.
If you bind a service class (not a service interface and class), then the service is fully instantiated the first time it is injected, rather than at that first method invocation. Further, you
can't use decorations or method advice on such a service.
The final reason for the service interface / implementation split is to nudge you towards always coding to an interface, which has manifest benefits for code structure, robustness, and testability.
My service starts a thread; how do I know when the application is shutting down, to stop that thread?
This same concern applies to any long-lived resource (a thread, a database connection, a JMS queue connection) that a service may
hold onto. Your code needs to know when the application has been undeployed and shutdown. This is actually quite easy, by using
a service builder method. In your module class:
public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub)
{
final MyServiceImpl service = resources.autobuild(MyServiceImpl.class);
shutdownHub.addRegistryShutdownListener(new RegistryShutdownListener()
{
public void registryDidShutdown()
{
service.shutdown();
}
});
return service;
}
This code uses the ServiceResources object to build an instance of MyServiceImpl, with all dependencies injected.
It also injects Tapestry's RegistryShutdownHub service and adds a listener. The example assumes that the service implementation
(but not the service interface) includes a shutdown() method.
A valid alternative to this would be to have MyServiceImpl implement RegistryShutdownListener:
public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub)
{
final MyServiceImpl service = resources.autobuild(MyServiceImpl.class);
shutdownHub.addRegistryShutdownListener(service);
return service;
}
It is not recommended that MyServiceImpl take RegistryShutdownHub as a constructor parameter and register itself as a listener Doing so is an example of unsafe publishing.
Change Notification Preferences
View Online
|
View Changes
[CONF] Apache Tapestry Tapestry Inversion of Control Container
Tapestry Inversion of Control Container
Page edited by Howard M. Lewis Ship
Changes (3)
...
to see if the actual service exists yet. If not, it instantiates and configures it (using proper locking to ensure thread safety), then delegates the method invocation to the service.
If you binding a service class (not a service interface and class), then the service is fully instantiated the first time it is injected, rather than at that first method invocation. Further, you
cant use decorations or method advices on such a service.
The final reason for the service interface / implementation split is to nudge you towards always coding to an interface, which has manifest benefits for code structure, robustness, and testability.
h3. My service starts a thread; how do I know when the application is shutting down, to stop that thread? This same concern applies to any long-lived resource (a thread, a database connection, a JMS queue connection) that a service may hold onto. Your code needs to know when the application has been undeployed and shutdown. This is actually quite easy, by using a service builder method. In your module class: {code} public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub) { final MyServiceImpl service = resources.autobuild(MyServiceImpl.class); shutdownHub.addRegistryShutdownListener(new RegistryShutdownListener() { public void registryDidShutdown() { service.shutdown(); } }); return service; } {code} This code uses the ServiceResources object to build an instance of MyServiceImpl, with all dependencies injected. It also injects Tapestrys RegistryShutdownHub service and adds a listener. The example assumes that the service implementation (but not the service _interface_) includes a {{shutdown()}} method. A valid alternative to this would be to have MyServiceImpl implement RegistryShutdownListener: {code} public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub) { final MyServiceImpl service = resources.autobuild(MyServiceImpl.class); shutdownHub.addRegistryShutdownListener(service); return service; } {code} {warning} It is *not* recommended that MyServiceImpl take RegistryShutdownHub as a constructor parameter and register itself as a listener Doing so is an example of [unsafe publishing|http://www.ibm.com/developerworks/java/library/j-jtp0618.html]. {warning}
Full Content
Tapestry Inversion of Control Container
Why do I need to define an interface for my services? Why can't I just use the class itself?
First of all: you can do exactly this, but you lose some of the functionality that Tapestry's IoC container provides.
The reason for the split is so that Tapestry can provide functionality for your service around the core service implementation. It does this by creating proxies: Java classes
that implement the service interface. The methods of the proxy will ultimately invoke the methods of your service implementation.
One of the primary purposes for proxies is to encapsulate the service's lifecycle: most services are singletons that are created just in time. Just in time means only as soon
as you invoke a method. What's going on is that the lifecycle proxy (the object that gets injected into pages, components or other service implementations) checks on each method invocation
to see if the actual service exists yet. If not, it instantiates and configures it (using proper locking to ensure thread safety), then delegates the method invocation to the service.
If you bind a service class (not a service interface and class), then the service is fully instantiated the first time it is injected, rather than at that first method invocation. Further, you
can't use decorations or method advice on such a service.
The final reason for the service interface / implementation split is to nudge you towards always coding to an interface, which has manifest benefits for code structure, robustness, and testability.
My service starts a thread; how do I know when the application is shutting down, to stop that thread?
This same concern applies to any long-lived resource (a thread, a database connection, a JMS queue connection) that a service may
hold onto. Your code needs to know when the application has been undeployed and shutdown. This is actually quite easy, by using
a service builder method. In your module class:
public MyService buildMyService(ServiceResources resources, RegistryShutdownHub shutdownHub)
{
final MyServiceImpl service = resources.autobuild(MyServiceImpl.class);
shutdownHub.addRegistryShutdownListener(new RegistryShutdownListener()
{
public
[CONF] Apache Tapestry Tapestry Inversion of Control Container
Tapestry Inversion of Control Container Page added by Howard M. Lewis Ship Why do I need to define an interface for my services? Why can't I just use the class itself? First of all: you can do exactly this, but you lose some of the functionality that Tapestry's IoC container provides. The reason for the split is so that Tapestry can provide functionality for your service around the core service implementation. It does this by creating proxies: Java classes that implement the service interface. The methods of the proxy will ultimately invoke the methods of your service implementation. One of the primary purposes for proxies is to encapsulate the service's lifecycle: most services are singletons that are created just in time. Just in time means only as soon as you invoke a method. What's going on is that the lifecycle proxy (the object that gets injected into pages, components or other service implementations) checks on each method invocation to see if the actual service exists yet. If not, it instantiates and configures it (using proper locking to ensure thread safety), then delegates the method invocation to the service. If you binding a service class (not a service interface and class), then the service is fully instantiated the first time it is injected, rather than at that first method invocation. Further, you can't use decorations or method advices on such a service. The final reason for the service interface / implementation split is to nudge you towards always coding to an interface, which has manifest benefits for code structure, robustness, and testability. Change Notification Preferences View Online
[CONF] Apache Tapestry Tapestry Inversion of Control Container
Tapestry Inversion of Control Container Page edited by Howard M. Lewis Ship Changes (3) h1. Why do I need to define an interface for my services? Why cant I just use the class itself? h2. Tapestry Inversion of Control Container h3. Why do I need to define an interface for my services? Why cant I just use the class itself? First of all: you can do exactly this, but you lose some of the functionality that Tapestrys IoC container provides. ... Full Content Tapestry Inversion of Control Container Why do I need to define an interface for my services? Why can't I just use the class itself? First of all: you can do exactly this, but you lose some of the functionality that Tapestry's IoC container provides. The reason for the split is so that Tapestry can provide functionality for your service around the core service implementation. It does this by creating proxies: Java classes that implement the service interface. The methods of the proxy will ultimately invoke the methods of your service implementation. One of the primary purposes for proxies is to encapsulate the service's lifecycle: most services are singletons that are created just in time. Just in time means only as soon as you invoke a method. What's going on is that the lifecycle proxy (the object that gets injected into pages, components or other service implementations) checks on each method invocation to see if the actual service exists yet. If not, it instantiates and configures it (using proper locking to ensure thread safety), then delegates the method invocation to the service. If you binding a service class (not a service interface and class), then the service is fully instantiated the first time it is injected, rather than at that first method invocation. Further, you can't use decorations or method advices on such a service. The final reason for the service interface / implementation split is to nudge you towards always coding to an interface, which has manifest benefits for code structure, robustness, and testability. Change Notification Preferences View Online | View Changes
