Technology Highlight: Focus on What We Do Best Product Roadmap: Ease of Deployment

Posted on by


In 2000, eOriginal made the risky decision to move from the “well established” Sybase PowerBuilder based software suite to the recently released Java based J2EE platform. With J2EE and the World Wide Web still in its infancy eOriginal was forced to develop its own proprietary frameworks that are now standard today in many applications.

One of the benefits to our original J2EE implementation was to allow the customer (or integrator) to develop their own product on top of ours.  What we call our Application Developer Framework (ADF) was our first release of this; it allowed customers to create their own “webflows” through a server side XML configuration file that would string together classes in order to perform a complex series of either RMI or RESTful web service calls as a single event handler.  It was also expanded to include customizations of every aspect of our software from everything to custom form validation, modifying button text, fonts, images, etc.

Many of the features within the eOriginal ADF framework have been developed into well-established J2EE toolkits like Struts and Spring.  The Apache Struts Project and Spring Frameworks have come a long way since 2000 and are now used by 1,000’s of organizations around the world.  For the last few years we have been migrating features previously supported by our ADF framework to Spring and Struts configurations.

Migrating to an industry framework has many benefits, we no longer have to explain our propriety system to new developers or to our customers looking to customize their behind the firewall installations.  A lot of our previous ADF framework was built upon existing J2EE specific functions (MDBs, JSPs, Servlets, EJBs), our goal is to keep simplifying the installation and footprint of our behind the firewall installations to completely remove the need for an application server all together.  eOriginal took one step closer to this goal by adding Apache TomEE support in 2014 in addition to our list of supported J2EE application servers.

In our 8.3 release we are continuing to integrate the ADF event handlers into the struts framework.  We have also introduced a new spring configuration file for each of these events handlers that are configured as spring beans.  By doing this, accessing other spring beans is a much easier process – they can be (and are) injected – rather than looked up in our own ApplicationContext encapsulated bean factory class.  This makes our application development much easier.  Previously our development team would need to manually create a service factory for each class:

public class GetBatchStatusEventHandler extends EOAbstractEventHandler<BatchStatusForm> {

public String execute() {

BatchService batchService = ServiceFactory.getBatchService();

DocumentProfileService dpService = ServiceFactory.getDocumentProfileService();

DocumentVersion dv = documentProfileService.getLastDocumentVersionDetail(sctx, dp.getSid());




Now this can be handled dynamically with our spring beans:

public class GetBatchStatusEventHandler extends EventHandler<BatchStatusForm> {

private BatchService batchService;

private DocumentProfileService documentProfileService;

public String execute() {

DocumentVersion dv = documentProfileService.getLastDocumentVersionDetail(sctx,dp.getSid());



   public void setBatchService(BatchService batchService) {

      this.batchService = batchService;


   public void setDocumentProfileService(DocumentProfileService documentProfileService) {

      this.documentProfileService = documentProfileService;



Since Struts, Spring, and ADF are all XML based, the learning curve of these new technologies is minimal, but that is not to say the transition has been without issues.  Our ADF framework allowed for a very complex WAR structure in which all of our WARS inherit for a single abstract WAR.  Within these WARS, there are web event handlers that use web services.  This inheritance caused a circular dependency on some of the new spring beans.  Thanks to the extensive spring documentation and user community we were able to see the problem was some of our property setters were trying to do initializations that relied on other setters having already been set.  We were able to deal with this by declaring our beans as implementing the InitializingBean interface.

Here at eOriginal we are very proud of the many proprietary technologies that were built to support our application during its infancy.  However as eOriginal, the internet, and J2EE applications grow it is important to grow with the times.  This allows our IT team to focus on our core eAsset Management product without having to worry about the development framework behind it.  Allowing us to do what we do best and the employees at RedHat, the Apache Software Foundation, Pivotal Software, and other leading companies to do what they do best.