The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

p2auljr (2) [Avatar] Offline
I have a design question regarding a POJO entity bean, dependency injection, and storing the POJO in the user's session.

For example, there is a web application where you update some entity through several "wizard" like screens. Then, this information is persisted to a database. The information is stored in a POJO entity bean that uses a data access object to persist the data. The access object is set through dependency injection using JavaServer Face's managed bean facility when the POJO is first needed. The POJO is then stored in the user's session.

Since the POJO entity bean is stored in the session, it must be serializable. However, I feel that the data access object should not be serializable b/c an implementation may be holding out to java.sql.connection or javax.sql.DataSource. So the dependency is marked as transient.

Now, the problem is that the dependency must be re-injected if the session is deserialized. This can be done my implementing a HttpSessionActivationListener.

Another option that I can think of would be to use a simple value bean/transfer object to maintain state and store that in the user's session. Then, create the entity bean at the end and pass the value bean to the entity bean. However, is this an appropriate case to use a transfer object?

On the other hand, if the POJO entity bean uses a ServiceLocator by calling a static factory method in its "save" method, then this problem does not occur. However, using the service locator pattern makes testing with mock objects more difficult.

Which is the best option or is there another option
that I have not thought of?

Thank you.
dserodio (4) [Avatar] Offline
Re: Dependency Injection, POJO entity, HttpSession
I'm using a ServiceLocator-based approach, but I'm not too happy with it either.
simbo1905 (30) [Avatar] Offline
Re: Dependency Injection, POJO entity, HttpSession
my thoughts are that a pojo entity works best if it is a pure business domain object. that is to say that it should not have references to a DAO that can save it. my understanding of the book is that the domain model was developed entirely independantly of the infrastructor to save it (session facade, repositories).

the way that I look at things the domain model models the "problem space" so it can and should be a self contained model. the infrastructure around them (JSF, DOAs, Facade, etc) model the "solution space". the solution should reference the problem but the model of the problem should not reference the solution. this is manifest in the book as the domain model is used again and again with different solutions (JDO, Hibernate, EJB3) with only annotations creeping into the domain model to support EJB3.

the database transactions are scoped to the facade. when the facade has returned the facade result object containing the pojo then that pojo, and any that it references, are disconnected from the database. the pojo can contain references to further pojos loaded within the scope of the facade method. no further lazy loading can occur though as the database connection has been returned to the pool.

the disconnected pojos are then "private copies" of the domain model frozen in time at the point where they were read from the databaes. these can be held in the httpsession for a very long time before ever (if ever) being passed into another facade method to save them back to the database after having been modified by the user.

i don't think that there are any spring config files in the sample code that do any dependancy injection on the pojo domain objects. all of the dependancy injection wires together the infrastructure around them.