One of the things we like about the Oracle Frameworks is open-ness and extensibility of the frameworks.
During our project we encountered the infamous web application problem of having two users edit the same data. The database and framework lead us to a few nice exceptions that resemble ‘RowInconsistentException’ or ‘RowAlreadyLockedException’.
The Oracle ADF Business Components framework gives us the possiblity of extending the transaction to catch this exception and do somethnig about it. We currently have decided that when these kind of exceptions are encountered that we want the transaction to be rolled back and a humanly readable exception to be displayed.
As an example we used the example of Steve Meunch (the Oracle ADF guru) and made this:
package nl.denhaag.grip.model;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import oracle.jbo.AlreadyLockedException;
import oracle.jbo.ApplicationModule;
import oracle.jbo.DeadEntityAccessException;
import oracle.jbo.DeadViewRowAccessException;
import oracle.jbo.JboException;
import oracle.jbo.Key;
import oracle.jbo.Row;
import oracle.jbo.RowAlreadyDeletedException;
import oracle.jbo.RowInconsistentException;
import oracle.jbo.ViewObject;
import oracle.jbo.server.DBTransactionImpl2;
import oracle.jbo.server.TransactionEvent;
/**
* Custom ADF DBTransaction implementation.
*
* Works in tandem with a custom DatabaseTransactionFactory implementation
* which returns instances of this subclass of DBTransactionImpl2
* instead of the default one.
*
*/
public class GRIPDBTransactionImpl extends DBTransactionImpl2 {
/**
* This framework method is called by clients to commit any pending
* changes in the transaction. It will first post any outstanding changes
* then issue the database commit to end the transaction.
*/
public void commit() {
try {
super.commit();
}
catch( JboException e ) {
handleException( e ) ;
}
}
/**
* This framework method is called by clients to validate all invalid
* objects in the transaction.
*/
public void validate() {
try {
super.validate();
}
catch( JboException e ) {
handleException( e ) ;
}
}
/**
* This framework method is invoked both by the postChanges()
* and by the commit() methods to post pending transaction changes.
*
* @param te TransactionEvent object
*/
protected void postChanges(TransactionEvent te) {
try {
super.postChanges(te);
}
catch( JboException e ) {
handleException( e ) ;
}
}
/**
* This framework method is called to actually issue the final
* 'COMMIT' statement to the database to end the transaction.
*/
protected void doCommit() {
try {
super.doCommit();
}
catch( JboException e ) {
handleException( e ) ;
}
}
private void handleException( JboException e ) throws JboException {
if( e instanceof RowInconsistentException
|| e instanceof RowAlreadyDeletedException
|| e instanceof AlreadyLockedException
|| e instanceof DeadEntityAccessException
|| e instanceof DeadViewRowAccessException
) {
rollback() ;
throw new JboException( "Een andere gebruiker heeft dezelfde gegevens ook gewijzigd. Uw wijzigingen zijn niet doorgevoerd, de nieuwe gegevens worden getoond." ) ;
}
else {
throw e ;
}
}
public void rollback() {
try {
// storeCurrencies
ApplicationModule appModule = this.getRootApplicationModule();
HashMap currencies = new HashMap() ;
String[] voNames = appModule.getViewObjectNames() ;
for( int voIndex = 0; voIndex < voNames.length; voIndex++ ) {
ViewObject vo = appModule.findViewObject( voNames[ voIndex ] ) ;
Row row = vo.getCurrentRow() ;
if( row != null ) {
Key key = row.getKey() ;
currencies.put( vo, key ) ;
}
}
super.rollback();
// reset Currencies
for( Iterator i = currencies.entrySet().iterator(); i.hasNext() ; ) {
Map.Entry entry = (Map.Entry)i.next() ;
ViewObject vo = (ViewObject)entry.getKey() ;
Key key = (Key)entry.getValue() ;
Row[] rows = vo.findByKey( key, 1 ) ;
if( rows != null && rows.length == 1 ) {
vo.setCurrentRow( rows[ 0 ] ) ;
}
}
}
catch (Exception e) {
if( e instanceof JboException ) {
throw (JboException)e ;
}
else {
throw new JboException(e) ;
}
}
}
}
It actually doesn’t do much. but enough for our purposes. For the framework you need to wrap this transaction implementation in a factory:
package nl.denhaag.grip.model ;
import oracle.jbo.server.DBTransactionImpl2;
import oracle.jbo.server.DatabaseTransactionFactory;
public class GRIPDBTransactionFactory extends DatabaseTransactionFactory {
public DBTransactionImpl2 create() {
return new GRIPDBTransactionImpl();
}
}
Even less code…
Now the magic to extend the framework: Open up your Configuration of your Application Module and goto the properties page. Scroll down all the way and find the ‘TransactionFactory’ property. Fill the with the complete classname of your own factory and presto….
Note: when using the BC tester to run your Application Module, make sure you choose the Configuration (at the top right of the screen where you select your connection) or your settigns won’t be loaded.
Spring is going Webservices! Or a bit more specific, Spring is going SOAP. Arjen Poutsma has sent this message to the world during the last NL-JUG J-Fall conference. On his blog you can find the nitty gritty details.
Personally I think it is a good idea to build a Spring based framework and not be dependant on special web service containers. But I can’t see the point of focusing on SOAP only. I know SOAP is the de-facto standard for building message based remote services. And I also see the point he’s making about the difference between message based and rpc-style invocation. But I do not see the reason to ignore other protocols. To express this, REST is mentioned in one of Arjens blogs: REST services seem to have very little common functionality that cannot already be captured with Java classes like the HttpServlet.
Okay, agree. But so what? Maybe I need to publish my beans as both SOAP and REST service? Maybe I’m stuck with a legacy message format? Maybe, for performance reason, I do not want to use SOAP? Maybe I’m not running on a servlet container but behind my own socket? And maybe I can come up with a lot more maybe’s? Both SOAP and REST are message driven protocols that share some common similarities. And those similarities can be expressed in a common interface or abstract set of classes. Loose coupling is one of the paradigma’s lite weight application design has been build upon! So, either convince me I’m wrong or extend your horizon in order to do remote invocation beyond SOAP.
By the way, a little side-step into API design. Suppose you have two interfaces specifying a method with the same name but a different return type, how on earth are you going to implement it in one class? So SOAPMessage invoke(SOAPMessage request) throws Exception in MessageEndpoint and Source invoke(Source request) throws Exception in PayloadEndpoint is maybe not a good idea. I know chances a rare in this case but you’ll never know how the dices will be thrown when you start playing.
[editorial note, I need to re-pass Sun certification. Please visit the comments section for clarification]
But, no matter if the people behind Spring-WS are going to change the previous mentioned points or not, I think Spring-WS is a good addition to the stack of available Spring modules. And definately worth the try!
During a java meeting about the use of (open source) frameworks there were a number of interesting conclusions. Frameworks are not used for the following reasons:
- Lack of knowledge by the team members.
Most projects are fixed date. To minimize risks, projects use the known solutions (based on experiences of the team). There is no time to select and test a possible (open source) framework and estimation is already based on a known solution. Besides all that selecting a framework is not an easy task, see what-is-the-best-java-web-framework. - Dependency of a framework on other frameworks.
Some frameworks depend heavily on other frameworks. This can make configuration management a nightmare specially when having multiple frameworks that use different versions of a common dependency. - Frameworks will be outdated in a few years.
This �feeling� is based on the rapid changing java-world. A framework like Struts is now history.
When open source frameworks are not used, what is? Most projects define there own solution and depending on the size of the project this will turn out to be a project specific framework. This has one big disadvantage: new project members need to learn this framework. For this framework the same rule applies as for open source frameworks: they will be outdated within a few years.
Is there an advantage using an open source framework? YES!
There is a good chance that your project is not the only project using the framework. When new colleagues on a project have knowledge of a framework they will be productive in no time. This works best as framework selection is done on a corporate level.
Are there more advantages ?? let me know!!
A few days ago JbBoss announced the beta release of a new EJB3 and JSF based application framework: SEAM. Yet another framework? Should I invest some time or just ignore it like all the others that came along the last one and a half year?
An interesting post on the groupblog of Hibernate opened my eyes and answered my question. Gavin King is behind this framework (One of the smartest moves of JBoss founder Marc Fleury was to contract the hibernate guy) and when Gavin is behind something, at least you’ll be able to find some interesting writings of his hand.
So I deceided to give it a try, followed the tutorial and found myself in regular JBoss stacktraces within minutes. Failure after failure. Somehow JBoss and I do go hand in hand conceptually but as soon as we’re getting pragmatic I’m lost in evergrowing error logs. Meanwhile I was reading all available documents I found about SEAM and fortunate, Gavin found himself some time to write some decent material (Especially chapter 2 of the reference guide is worth some investigation). Although my first experiments failed completely, Gavin convinced me SEAM might bring back EJB to the development floor.
Why? Simply simplicity! Old style EJB is both overwhelming complex and not realy developer friendly in usage. Well the new EJB3 spec is still overwhelming complex but most of this complexity is well hidden for the regular developer. And SEAM brings just that extra facade on top to hide it completely. Another reason: Seamless integration with JSF. With SEAM, using JSF feels like a breeze.
So will SEAM replace Spring like Spring replaced the usage of old dirty EJB’s?? No idea but I’m sure someone is going to write a book ‘Look mam, J2EE *with* EJB’s’ and what will follow is whatever follows the hype. Untill then I’ll try to get something useful out of SEAM and come back to this blog later on.
P.S. Complete offtopic but the only reason I started investigating this framework is because SEAM is just one of my favorite alternative indiestyle pop bands of the ’90s.
The never ending religious war about frameworks, which to use for what purpose in combination with yet another framework, will probably really never end. Nothing wrong with that, good discussion about the technical fundamentals of your next j2ee project can better be fought out before you start coding. But instead of fighting, it might be wise to look around and see what others have been done. Matt Raible, author of Spring Live, has spend his time writing a kind of uberframework which leaves questions like ‘to Struts or not to struts?’ and ‘to Hibernate or not to hibernate’ up to you. Using Appfuse you’re up and running within minutes while you still can fight your lovely war. And when you think Appfuse is a bit to heavy for your duties, take a look at its little brother Equinox.
