I am separating some functionalities in Project Dune. Transaction control was initially handcoded in each service request, but there were two problems here. The service request started the transaction in an HTTP specific stub and the business logic was mixed with this protocol-specific code. So the separation puts the business code into a separate object and transaction control is managed on any method that this business object does.
The first attempt actually was a transaction filter that always creates a transaction and then closes it, but this is expensive and one problem with GWT is that the SerializableException gets consumed and serialized as a response stream. So the filter will never see this exception being raised.
I have thus used Guice (pronounce this as "juice") to deal with these problems. The way it works is like this:
- A servlet context listener is used (see web.xml configuration) to initialize a Guice Injector and bind this to an attribute into the servlet context.
- A servlet filter always opens a Hibernate session. (not a transaction!). It will also (try-finally) close this session.
- When a GWT service needs to service a request, Tomcat will create the specified servlet.
- Each servlet derives from a BaseServiceImpl abstract servlet.
- The BaseServiceImpl overrides "init( ServletConfig config )". Through the "config.getServletContext().getAttribute()"
- I am retrieving the injector object, created in the listener.
- The injector object calls "injector.injectMembers( this )", which will "instrument" any annotated members in the servlet instance.
- When the injector sees a request to inject a field or method parameter, it will look this up in the registry and also attempt to inject any annotations that may exist in the to-be-injected instance.
- And so through very simple annotations, it may result in a couple of cascaded injection requests when a servlet gets instantiated.
The very nice thing about Guice is that you no longer have to deal with XML files. It is all programmatic. As soon as you have your "injector" instance, this instance will have been configured with a couple of bindings. Those bindings have matchers on classes and methods and if it finds anything that is annotated, it will perform that instrumentation.
Notice however that Guice is *not* installed on the classloader. This means that just setting "@Inject" on a field for example will not do anything *unless* you retrieve the instance through the injector instance. This latter part is not very easy for
everybody to understand right away, but is the most important aspect (no pun intended) about Guice programming as I have found so far.
Code example? You will need aopalliance.jar and guice-1.0.jar for this to run, downloadable from the Guice website:
ServletContextListener:
================
public class GuiceServletContextListener implements
ServletContextListener
{
public GuiceServletContextListener() {
super();
}
public void contextInitialized(ServletContextEvent servletContextEvent)
{
ServletContext servletContext =
servletContextEvent.getServletContext();
// Create our injector for our application use
// store it in servlet context.
Injector injector = Guice.createInjector( new TransactionModel() );
servletContext.setAttribute( Injector.class.getName(), injector );
}
public void contextDestroyed(
ServletContextEvent servletContextEvent)
{
}
}
TransactionModel:=============
public class TransactionModel implements Module
{
public void configure(Binder binder)
{
binder.bindInterceptor(
any(), // Match classes.
annotatedWith(Transactional.class), // Match methods.
new TransactionInterceptor() // The interceptor.
);
}
}
Transactional:==========
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
public @interface Transactional {
}
BaseServiceImpl (a base class for any servlet in the application):
==========================================
public abstract class BaseServiceImpl extends RemoteServiceServlet {
.....
@Override
public void init(ServletConfig config) throws ServletException {
super.init(config);
Injector injector = (Injector)config.getServletContext().
getAttribute( Injector.class.getName() );
injector.injectMembers( this );
}
.....
}
CustomerServiceImpl (implementation of GWT service):
====================================
public class CustomerServiceImpl extends BaseServiceImpl implements CustomerService {
......
@Inject
private CustomerBO customerBO;
......
public CustomerDTO saveCustomer( CustomerDTO dto, boolean isNew )
throws UIException
{
try {
Customer customer = customerBO.getCustomer( dto.getCustomerId() );
if ( customer == null ) {
checkAccess( WebConstants.CUSTOMER_ADD );
// not found, so create it.
customer = new Customer();
} else {
checkAccess( WebConstants.CUSTOMER_EDIT );
}
MapperIF mapper = DozerBeanMapperSingletonWrapper.getInstance();
mapper.map( custDTO, customer );
customer = customerBO.saveCustomer( customer, isNew );
CustomerDTO dto = customerBO.getCustomer( customer.getCustomerId() );
return dto;
} catch (ApplicationException ae ) {
log.error( "Could not save customer", ae );
throw new UIException( ae.getMessage() );
}
}
......
}
CustomerBO:=========
@Singleton
public class CustomerBO extends BaseBO {
......
@Transactional
public Customer saveCustomer( Customer customer, boolean isNew )
throws ApplicationException
{
Session session = getSession();
try {
if ( isNew && customer != null ) {
throw new ApplicationException(
custI18n.getMessage( "error.cust.already.exists" ) );
}
// validate will raise an ApplicationException if the customer data is invalid.
validateCustomer( customer );
if ( isNew ) {
session.save( customer );
} else {
session.update( customer );
}
customer = getCustomer( customer.getCustomerId() );
return customer;
} catch (HibernateException he ) {
log.error( "Could not save customer", he );
throw new ApplicationException(
custI18n.getMessage( "error.save.customer" ));
}
}
}
==========================
Obviously this code can/should be extended with a variety of things. It should probably check if there is already a transaction ongoing. It should probably add parameters to the transaction interface to find out how the method supports transactions (required, supports, requiresNew, etc) and so on. But for simplicity's
sake, this is the bare minimum.
Notice how, once you have started the injector in the ServiceImpl, the CustomerBO does not need to be declared specifically in the injector. This is some sort of automatic cascading injection effect which happens because the injector is already processing dependent classes. So, luckily, you only need to use the Injector once, which will inject all your other classes where you want them.
Also have a look how to do this for interfaces. What is lacking in the CustomerBO is a separation of persistence with business logic. If you separate this further, you have a start to be able to switch the implementation of your persistence framework.
I am personally contemplating to bring the transaction boundary more forward and wrap this around the methods (where required) of ServiceImpl instead. But I am not sure whether this will work.
Good luck on your own incantations!
Some cartoon art
This is a modification of a fractal. I basically heavily embossed it and layered the result on top of the original. Then grayscaled part of the picture for a concrete effect and layered other images over it for a sort of glass like effect. As you can see, I don't master glass yet, which is why I started with the following image, one of an orb over a newspaper. That one looks much better.
This orb is produced solely under photoshop. It started with a simple sphere in a flat color, than I added an inner shadow effect to create some white at the bottom right (it should have more in the final image). Then another gradient in the middle, which was masked by a radial gradient. A hotspot in white at the top and then a selection of the initial orb that had a fill of black and transparency, which was scaled down to about 40% in height, slightly blurred and slightly moved to the right. The glasses and newspaper are from a photo. And the problem I run into obviously is not paying attention to the existing shadows in the picture :).
I just bought a Wacom tablet to also pay attention to a different kind of creativity. I never really drew anything in my life basically, but the computer helps a lot with imagery in many cases. This one is called "beauty", but then in Japanese :).
I am separating some functionalities in Project Dune. Transaction control was initially handcoded in each service request, but there were two problems here. The service request started the transaction in an HTTP specific stub and the business logic was mixed with this protocol-specific code. So the separation puts the business code into a separate object and transaction control is managed on any method that this business object does.
The way how machine communication is evolving is starting to change, more into a conversation with hints provided by the system to improve efficiency then a list of operations to execute one after the other. The machine initially started as a processor to receive a list of holes on paper, which would process inside the machine, with the output of another paper element that had values on them.
I haven't written a lot here, nor have released any new version of Project Dune because we are writing a lot of new functionalities. This image shows a crude task burndown graphic for SCRUM project management. The module that we created basically is aimed to allow users to very quickly manage the states of their tasks for projects they are assigned.
It's getting carnaval again. Starts this week. On Friday, everyone will power down the machines and they start a party in front of the building.
Project Dune went stable yesterday. It still needs a detailed customization guide and a user's guide to be really complete, but the main beef is there for people to use and to provide feedback on.
I have had the opportunity to work on many different kinds of projects, and you cannot treat software development for embedded hardware the same as web server application development, not by any long shot.
MS Vista has been delayed a couple of times and this is often attributed to different factors. This article shows how Windows did the version management. Check it out:
There are different methods for project management besides the "Project Management Body Of Knowledge". The ancient "accredited" methods put a single guy as the responsible person for finishing and executing a project. This is just an observation at this point.
Posts
