|
|
|
This is one of those releases you always hope you never have to do, but hey bugs happen. So yes, this is a maintenance release that fixes a number of bugs. There are also a couple of new features, but not many.
Bug Fixes include:
New features and improvements include:
Once again we have another great release. This release includes a number of new features and a major refactoring and cleanup of the ecommerce application. Most of that refactoring and cleanup was part of our move away from JSPs and toward a new presentation view architecture using JPublish, FreeMarker, and BeanShell. As with all components used/included in OFBiz these tools are freely available open source projects with active and accessible development and user communities. Because of all of the new features including this new architecture, this release will not be a maintenance release following the 2.0.x series, but rather a new minor release starting the 2.1.x series.
All of the ecommerce webapp has been changed from the old JSP/Regions architecture to the new JPublish/FreeMarker/BeanShell architecture. The ControlServlet and events are all the same as before, this just replace the "view" portion of the presentation layer. Very few pieces of the other applications have been migrated to this new architecture, but that will be done over the coming months.
Another major new change is the integration with the JOTM transaction manager which is a replacement for Tyrex. This means that a very simple configuration can now be deployed with only a servlet container and a stand-alone transaction manager, and without the difficulties that Tyrex brings with it.
This release is the first that includes our new recommended open source platform which now consists of Jetty and JOTM instead of Tomcat and Tyrex. Jetty makes deployment of OFBiz much easier than it was under Tomcat because there is no longer a need to copy the nearly 100 jar libraries and configuration files into the app server directory as was necessary with Tomcat. In addition to moving to Jetty, we are also introducing the new ofbiz.jar startup program. This new executable jar embeds Jetty/JOTM with OFBiz, auto-sets all classpath and required settings. By running java -jar ofbiz.jar from the root OFBiz directory will fully start OFBiz in a cross-platfrom way.
New features and improvements include:
There have been a lot of incremental improvements in this release, and some major additions as well. Considering what has been worked on you can all probably guess that we are starting to take a new direction with the project. The framework and many of the existing applications are maturing well and are quite stable.
So, we are doing a "stable" release and starting to push effort in the direction of filling in the gaps in the applications. Soon to come are major improvements to the Work Effort application and we'll be starting on the Accounting and Content Management (also includes knowledge management) applications. Other applications and components will receive attention and be incrementally improved, especially as they are more widely adopted.The Order Management and the order related pieces of e-commerce are incredibly improved. The Workflow Engine is now used for order management and will be used for many other processes in the future. The setup pages have been improved and better organized to make it easer to start taking orders. More reporting and statistics have been added, but these are just getting started. Expect a lot more reports in the near future.
The Catalog Manager has been improved, but the most work in that area has been done on the Facility Manager which now handles shipping, receiving, inventory transfers and store, warehouse and inventory management.
New features and improvements include:
It's amazing that another four months have passed since we did the last OFBiz release. August through October are always the big crunch times for e-commerce sites hoping to go live before Christmas, and this has resulted in some significant improvements in the feature set and stability of OFBiz. In addition to all of the e-commerce features that got pushed forward, or along with them really, we have started getting into marketing and many extensions have been added to the WorkEffort and Party Managers.
Some of the future directions mentioned before are starting to take place, but there is a lot left to do there. Note that we are not planning on getting all of these done for the 2.0 final release, in fact we aren't planning anything really huge for 2.0 final. Actually, we are planning on going to a new versioning scheme where the initial "stable" 2.0 release will be 2.0.0, and then we will do minor and major version increments as seems appropriate given the work done since the previous release.
There are a few more third party packages included in this release: the JasperReports and DataVision reporting tools with ViewHandler implementations for the web controller and the WEKA data analysis package which is really best used as a stand alone Java GUI application hitting a database or exported data files directly. There will be more third party packages and more use of these packages as the project continues.
We have tested a number of additional app servers for production, and because of the difficulties we have had with Tyrex as a transaction manager we recommend using something else. The best commercial options we found were Orion (www.orionserver.com) and JRun4 (www.macromedia.com). In addition to these commercial products the newer versions of Tomcat (in the 4.1.X series) are running extremely well and are close to Orion and Resin in speed. For Tomcat you can run with Tyrex if it is sufficient for you, but you may want to consider using parts of JBoss for transaction management, JMS, etc. Adjustments have been made to OFBiz to be able to handle various quirks and funny things in these and other app servers.
New features and improvements include:
Since Beta 1 of 2.0 was released in March a lot has been added to OFBiz. We were planning on doing cleanups and stabilization work and moving towards a 2.0 Final release, but some contracts came up. This is both good and bad. The bad part is that 2.0 Final is getting delayed, the good part is that a whole lot has been cleaned up and completed, and even more has been added.
Most of the new features are centered around making a feature rich eCommerce package that competes nicely with commercial alternatives. The Catalog, Order and Party Management applications have matured right along with eCommerce and are now sufficient for managing data behind the eCommerce site.
New eCommerce related features include:
In addition to all of these the data model has been cleaned up and added to a great deal and many pieces of the project have been refactored or completed.
So, what's next? There are a few areas we are planning on focusing on (the key word being "planning"):
Some of this functionality will not be a lot of work and may be included before 2.0 Final is released, but this list is really more of a near term set of goals from our long term list that will realistically take a few months to get in place initially and refinements and improvements may continue for years.
Onward and upward!
This first beta release of version 2.0 represents the completion of all of the main components of the OFBiz framework. Other framework components will be added as the project progresses, but the most important architectural enablers are now in place.
A number of people have contributed to this release that are regular users of Open For Business, including (in no particular order) Chris Nelson, Chris Worley, Mike Cannon-Brookes, Victor Salaman, Dustin Caldwell, and Ian Pojman. In addition to these people we have received recommendations and feedback from dozens of users and enthusiasts of OFBiz. Thanks everyone!
This release includes a number of bug fixes and cleanups that have been uncovered by use of the software in the project, and now that it is in beta we would like even more help making sure things work as expected, and as desired.
There are a few changes in the way things work in this release. Both the Entity Engine and the Service Engine are now configured through XML files instead of properties files, which makes the configuration easier, and enabled some additional options. One of the main additional options for both is the ability to load the entity and service definition files through various loaders, including file, URL and classpath loaders. This allows applications to be completely contained in JARs, WARs, and/or other archives.
The Webapp Framework now includes an implementation of the Composite View pattern with a Regions package very similar to the one in the book "Advanced Java Server Pages" by David M. Geary. Along with the addition of support for Velocity views that makes a total of three view types available: JSP, Velocity and Regions.
The set of available events types now includes 4 options: java, soap, service and simple. The simple-method MiniLang can now be used for both events and services.
The simple-method MiniLang has been greatly expanded and improved. MiniLangs are Ant-like scripting languages used in OFBiz to perform high level tasks and tie together and simplify components.
Simple methods can now be called as either Events or Services. Tags for conditional execution, Entity Engine operations, executing BeanShell scripts, executing inlined simple-map-processors (or external ones), performing various environment operations, and even calling other simple-methods in the same context have been added.
A number of improvements have been made to the Workflow and Service Engines. A number of fixes and flexibility features have been added to the Workflow Engine. Both engines have improved support for scalability and running multiple identically configured servers against the same database. This includes support for having all servers in a "cluster" sharing the load of asynchronous execution of services and workflow processes.
The Rule Engine is still not mature, but many features are complete and can be used for a number of purposes. Numerous examples of using the engine are included and a document is now in place describing the Rule Engine, the concepts behind it, it's current state and future plans, and an explanation of how to use the API.
A number of improvements have been made to the applications. The most notable changes include the user of the Regions (Composite View) package, and the more consistent use of CSS for the look and feel of the applications.
A few features and improvement have been added to eCommerce, the Catalog Mgr, the WorkEffort Mgr and the Order Mgr.
The focus for version 2.0 has been the completion of the basic components of the framework. The future focus will be more on the implementation and expansion of applications. This will especially be the case after the 2.0 final version is released.
This release includes many cleanups and adds the capability of running on various J2EE app servers including Tomcat4, Jetty4, JBoss, Resin, Orion, and Weblogic. Some profiling has been done on this release and changes were made that result in a performance increase of many time. On Orion, the fastest container that we've tested, we got a volume of 400 dynamic catalog browse pages per second on a PIII 1Ghz with 20 continuous threads hitting the machine. Caucho Resin was the second fastest (the two being far faster than the rest tested) and came in close behind.
A number of cleanups and refactorings have also been done. The profile code in the eCommerce package is now uses the new Party module services through the SimpleEvent and SimpleMapProcessor Mini-Languages. Other components are moving in this direction.
In addition to the cleanups, performance increase, and deployment options a number of new features are included in this release in the Catalog Manager and eCommerce applications and various parts of the core framework. The Control Servlet also now gathers statistics about resource hits and response times. Logging is now done through Log4J and is more granular than before with more useful and less verbose (unless verbose is turned on) logging has been adopted in many parts of OFBiz.
A number of tasks have been planned and completed for this release, in addition to the many smaller refinements and changes that have been done. These tasks include:
The 2.0 Alpha 1 release represents a MAJOR step forward for Open For Business, as have many releases before this. This release is an Alpha release because there are so many new pieces that have not been extensively tested, and in some cases are missing some functionality. Other pieces are beta quality or stable, like the Entity Engine and the eCommerce application.
The Web Controller includes the controller servlet, the request processing classes as well as the event handling classes. The request mappings XML DTD has been revised, supporting improved response handling, the event handling has been re-designed to allow for different types of event handlers. New event handlers have been implemented to support features such as the SOAP interface listener for the Service Engine (see below) and the new SimpleService Mini-Language (see below). (stable)
The Service Engine is the tool that allows us to organize our applications around internal services that can seamlessly be exposed as web services, or can be implemented using remote web services. It provides a simple interface so that the caller does not have to know what language the service is implemented in or where that service is located. Service definitions are done in XML. (stable)
The Entity Engine now support JTA transactions. The default implementation is done with Tyrex from Exolab, but can easily be adapted to run with J2EE application servers like JBoss, Weblogic, etc. The Entity Engine now also provides an easy way to do joins with View Entities and has more flexible find methods, especially the findByAnd that accepts a List of EntityExpr objects to constrain the query. (stable)
The Workflow Engine makes it easy to layout and execute business processes as part of a J2EE application. It is based in the XPDL and other specifications from WfMC and the Workflow Management Facility Specification from OMG. It takes advantage of and is well integrated with the OFBiz Service and Entity Engines. Workflows can be invoked synchronously or asynchronously and locally or remotely through the Service Engine, and any activity in a process can be implemented as a service. (alpha)
The Mini-Languages are XML files that describe simple processes making common operations fast and easy to write and maintain. At the moment the existing languages make it easy to create events to validate and convert form input and pass it on to a service. Future extensions will allow complete applications to be written using JSP, XML Mini-Languages, and Entity and Service definitions. This will be anywhere from 5-10 times as efficient as coding these common components in Java. (beta)
The Rule Engine makes it easy to express and execute business rules and constraints. It is based on modern standards like RuleML and the mature language Prolog. It is written in Java and runs with an application in the same JVM, and can be invoked locally or remotely through the Service or Entity Engines. It can also call back into Services as sensors or effectors and integrates seamlessly with the Entity Engine to expand your knowledgebase in a ruleset to all of the data in your relational database. The Rule Engine is only partially in place and certain features are still in planning. (alpha)
A number of tasks have been planned and completed for this release, in addition to the many smaller refinements and changes that have been done. These tasks include:
This release includes a number of clean ups and refactorings in addition to many new features in the eCommerce application, the Catalog Manager application, and the many tools included to make development, maintenance, and administration faster and easier.
We are calling this release 1.0 Beta 1 and it is being released in preparation for the final version 1.0 release of Open For Business. Version 1.0 will include the eCommerce application, the Catalog Manager, and the many tools and components in the framework such as the Entity Engine, the Control Servlet, and the Data Model. It will also contain a "sneak peak" at the upcoming Generic Services Framework, the Workflow Engine and the Rules Engine which will be the primary elements of the version 2.0 release.
The complete download is now configured to use the Hypersonic SQL Java database so that a complete installation is included in the release. This means that installation for a demonstration or playing with it is as easy as 1) download it, 2) put it /ofbiz/work and 3) run it! This includes a sample database which is prebuilt so you can run the various applications immediately.
Of course, all of the configuration options are available still, including using various other databases. Starting from nothing with a new database is easy because the Entity Engine can create all of its own tables and check them, and initial data is included in XML and SQL files.
A number of tasks have been planned and completed for this release, in addition to the many smaller refinements and changes that have been done. These tasks include:
This release is the first major release of the Open For Business Project. The last two months have been very busy for those involved with development. The current software is now being used in commercial projects and will soon have a number of deployed sites. Because of the many changed in this release, I am going to keep these release notes on a higher level and not put too much detail in about specific features.
The first real user facing application (eCommerce) is essentially stable and now available for use. The catalog management tool is in place with very basic features and more to come soon. After running into some major design inconveniences and doing some refactoring, the data handling layer is not looking very good. There are also a number of tools available for management of data and data definitions.
This release of Open For Business can run entirely on Tomcat and the default platform is Tomcat 4.0, or Catalina. With the new Entity Engine CMP Entity Beans are no longer necessary for persistence, so JBoss is not required for simple deployments. For larger scaled deployments JBoss or any other EJB container can be used by the Entity Engine as a persistence server to take the persistence related transaction load off the JSP/Servlet servers. This can be done through some simple configuration changes.
The first release of the eCommerce Application is included in this release of Open For Business. It has been tested a fair amount and is running very nicely. There are three integrated modules in the current eCommerce application: catalog, user profile, and order. The catalog module provides all of the product and product category browsing and finding products through a keyword search that supports wildcards, and a separate web application is included for editing catalog information. The user profile module has general contact information functionality in addition to personal information, credit card information, and user login or login account information. The order module allows customers to place orders using a shopping cart, view their order history and status, and even reuse old orders by adding them to the cart.
The old Entity Code Generator has been deprecated in favor of the new dynamic Entity Engine. The OFBiz Entity Engine is the first of the major Common Tool Components of the Open For Business Architecture. The Entity Engine is dynamic in that none of the code in the engine is entity definition specific. It is all generic code that supports the persistence of any entity defined in its XML files. These defined entities can be communicated over any interface and to or from any data source the has an implementation of the GenericHelper interface. Documentation for the Entity Engine is located in ofbiz/core/docs/entity.html.
The architecture used in commonapp for separating presentation logic from other logic and handling authorization was done with a dispatcher that was invoked by each JSP. The new servlet controller handles not only the separation of presentation logic from other logic and security authorization, but also provides a way to control the flow of the application and externalize that from the events and views.
The definitions to control the servlet controller are specified in an XML file whose location is specified in the web.xml file. This file can be used to define requests and the events and views that correspond to them, the security settings for them, and is also used to define view maps. The controller is designed to be flexible so that many advanced things can be done easily with it, such as logging in or adding an item to the shopping cart, and staying on the same page. It also provides added simplicity for the JSPs by allowing the combination of views and events in a request such as the UpdateUserLogin request which calls the UserLogin update event, and on success forward the user to the ViewUserLogin view, which is then mapped to the appropriate JSP.
The servlet not only acts as a controller for the web application and its views and events, but also has a job scheduler so that events can be run repeatedly. An XML file is used to specify optional start and stop date/times, intervals and interval units, the event to invoke, and parameters to pass to the event. The location of this XML file is also specified in web.xml.
The servlet controller is in the new 'core' module. A number of classes have been moved from the commonapp module into this module, namely from commonapp.common to core.util. This is part of a move to remove from commonapp everything that does not fit the definition of its purpose. The commonapp module is meant to contain the Common Application Components as described in the architecture documents. It will contain the entities shared by all of the other applications in the ofbiz project. This includes the entity beans, administration pages, and other pieces that are entity based.
A number of enhancement have been made to the entitygen module, and the code in the commonapp module has been regenerated to reflect the changes to the templates in the entitygen module. Following is a list of those changes, and their corresponding task ids on the SourceForge site.
A number of other small changes have been made that are not associated with tasks. These include making EntityHelper generated classes more thread safe, and the use of the core.util.Debug class for logging debug messages.
Entitygen now uses a cache for each entity definition it reads from the XML data descriptor file. This dramatically speeds up the generation of source code, especially for large definition files and generation of all files and snippets for each, or for all, entities.
The CommonApp module now uses the basic user login and security entities from the big Data Model. Also, the data model has been organized, expanded, debugged and partially tested. All files and snippets generate succesfully, and all Java files compile successfully and with the generated deployment descriptors they deploy successfully in JBoss. Even with all 401 of the entities, JBoss starts up in less than a minute on my 500Mhz Athlon. All SQL files run successfully in MySQL.
The Data Model has been cleaned up and expanded. The datamodel-data.sql file is now cleaned up and works with the data model definition in the new datamodel.xml file. Part of this included adding tables to make the main entities extensible, and cleaning up the tables that are already there. Also, the Content module has been enhanced significantly to support very flexible content organization. Relations have been defined for the Content module, and for the entities which implement the extensibility of the main entities.
All of this brings the total number of entities in the data model to 401. The datamodel.xml file is now almost 9,000 lines long and is about 540Kb large. With the speed ups and all of these entities it takes about 45 minutes to generate all of the files on my 500Mhz Athlon. It generates 2630 Java files, 1203 JSP files, and about 2Mb of snippets in 8 files. Running wc on these files shows a count of 954,865 lines, 3,074,034 words, and 35,290,606 characters.
With this progress in place the Open For Business Data Model is now ready to be used as a basis for the various applications that we wish to build. As each application is built it will probably require various changes to the data model, but the basis is in place and is essentially bug free.
A number of lurking bugs have been fixed in this release in the entitygen templates and some of the commonapp support code. While generating and test compiling and deploying all of the Data Model entities a number of bugs and omissions were found and corrected. Also, some small restructurings (especially with EntityWebEvent.java) and additions to the templates make deploying the generated entities into an application is much more simple.
It's been a while since the last release, but I assure you, this one will be worth the wait! Actually the biggest reason for the delay was my two week vacation to the United Kingdom, mostly Wales and Scotland. Enjoy this new stuff!
Instead of right clicking on each file and saving from the entitygen main page, you can now specify a root directory and generate all Java or JSP files in directories under the root directory which correspond to the package name for each entity. The files are generated in a ready to use state (given no bugs in the templates or data definitions). This is done with a JSP which uses an open source library to retrieve the contents of a URL, and then saves those contents to the corresponding file under the specified root directory and package directory. The library used for this is from the open source project JoBo which can be found at http://www.matuschek.net/software/jobo/index.html. Thanks for making some cool stuff Daniel!
This is a very exciting new part of the project. The file ofbiz/commonapp/entitydef/datamodel.xml contains definitions for about 288 entities covering common areas of business data. This effort stems from browsing a bookstore a finding two excellent books by Len Silverston called The Data Model Resource Book Revised Edition - Volumes 1 & 2, published by John Wiley & Sons. This is a good starting point for any enterprise system development effort. Changes will be made to this model over time to expand and (hopefully) improve it. Industry specific models to be used along with the main model will also be added to the project over time. Many Thanks to Len Silverston. Anyone using these models will no doubt benefit from having a copy of his books on hand. These models include models for: parties (persons, companies, etc.) products & catalogs, ordering, invoicing, shipping, accounting, human resources, work effort & flow, and content management.
Using the new automated code generator, it is easy to build the EJBs, JSPs and other code related to these entities. A few interesting stats: 292 entities, 877 JSPs, 1606 Java Files, 9 snippet files (one for each type of snippet, just to get a size on them), totaling ~23 Mb, ~650,000 lines, ~2,100,000 words, ~23,800,000 characters. The XML definition file alone is about 4500 lines long. And yes, it does take my poor little 500Mhz Athlon a while to generate all of this code (around 2.5 hours for all of it). I am not including all of this generated code right now, and I don't plan to until the definitions settle down more and some of this stuff is actually tested, if ever. I may create a separate distribution for it too.
All generated ViewEntity.jsp files now take advantage of the relation definitions in the XML descriptor file. There are two types of relations: one and many. For a one relation, a view of the related entity similar to the normal view is created and a links as well. For a many relation, the corresponding finder is called and all results are listed in the page. This is a neat thing to see. You can now create an order entity, an order line item entity, and link them up to create a fully functional order entry system, or catalog browsing, or whatever you might want to do with relational entities. Note that the relations for the data model mentioned above are not yet finished. I can't wait untill they are!
More data types are now supported in the generated JSP files for field entry and display, including primary key fields. Also, the ValueUpdate methods in the EntityHelper and EntityBean files are changes so that they only update a field when it is not null. This is an easy way to specify whether or not each field should be updated. To set a field to null, simply use the field specific setter.
This release includes updates for the new versions of JBoss and Tomcat. JBoss version 2.2.2 and Tomcat version 3.2.2 are now being used.
All EditEntity.jsp files from the Entity Code Generator (including the current entity admin pages) now support server-side input validation. The validation routines can be found in commonapp/src/org/ofbiz/common/UtilValidate.java. Many of these validation routines are based on the Netscape JavaScript validation package (FormChek.js). They have all been converted to Java and modified to work in the server-side validation context. Some additional validation routines have also been added. The current library of validators includes everything from not being empty to algorithmic verification of credit card numbers to a validator for email addresses.
The Entity Code Generator automatically uses the validators specified in the XML entity descriptor file. This file for commonapp can be found in /commonapp/entitydef/commonapp.xml. Any number of validators can be specified for each field of an entity.
In the JSP when the user has an error, all of the data on the page is maintained and a full list of all current errors is displayed in a red list at the top.
Field types can be defined in each XML entity descriptor file. Each field type definition specifies a field-type name, and a java-type, a sql-type, and any number of validate elements. Once a field-type is defined it can be used by any field definition of an entity definition in the descriptor file. The field-type is used in place of the sql-type, the java-type, and may specify some validators. If a sql-type or java-type is used in the cmp-field definition, they will override the field-type defaults. If validators are specified in the cmp-field definition they are added to the validators from the field-type.
A first attempt at a list of common field types has been added to the beginning of /commonapp/entitydef/commonapp.xml. Some version of these field types will be used in every entity definition file in the project. This makes the XML descriptor code more concise and provides for more consistency in data type definitions.
The data layout of the XML Entity Descriptor file for specifying entity relations has been defined. the /commonapp/entitydef/commonapp.xml has a number of examples of how this feature might be used. It supports nested relations and relations where one or many instances of the related entity may be returned depending on how the relation is defined.
Entity relation definitions will be used in two main places: the JSP ViewEntity.jsp file to show information related to the current entity and provide for easy access to viewing and editing related entities; and in the Entity.java file to provide convenient methods of looking up related entities. NOTE: These have NOT been implemented yet. The relation data model is in place in the current release of ofbiz, but it is not used in any of the templates.
A call to reponse.encodeURL has been added to all <a href>s and all <form action>s to support session management with cookies turned off. All existing JSPs in the project support this, and all JSPs generated by entitygen support this.
Three JSPs have been added along with a number of web event handlers and extensions to the UtilCache class.
First of all, a number of bugs have been fixed in the UtilCache class making the caches actually work now.
The expire feature has been enhanced so that whenever get() or containsKey() are called hasExpired() is checked and on expiration the element is removed from the cache. The get() method will then return null, not being able to find the element, and the containsKey() method will return false, also not being able to find the element. This becomes simply a cache hit and the routine which uses the cache will load the value the normal way.
All caches have a name that they pass to the constructor and then initialization parameters are loaded from the conf/cache.properties file. If no name is passed, a default name is used with a number appended to it to make it unique. A Hashtable now stores a collection of all of the caches so that they can be maintained easily through a generic maintenance utility.
The JSPs that have been added are common/FindUtilCache.jsp, common/EditUtilCache.jsp, and common/FindUtilCacheElements.jsp. All cache parameters can now be viewed in real time including cache size, hitCount and missCount, and maxSize and expireTime can not only be viewed by changed through the JSP interface. The pages are permission protected using the security system. Individual cache lines can now also be viewed, and removed, through the JSP interface.
The Security class now has two caches (using UtilCache) to speed up the hasPermission() and hasEntityPermission() methods. The first cache stores a collection of security groups for each person. If a person belongs to no security groups, an empty collection is put into the cache so that those look ups will be fast too. The second cache corresponds to the SecurityGroupPermission entity and caches Boolean values keyed on a SecurityGroupPermissionPK. The Boolean value is true if the corresponding SecurityGroupPermission entity exists in the database, or false if it does not.
All EntityPK, or primary key, classes now override the toString() method to make display of primary key information more simple and consistent.
This initial release includes the first version of the Entity Code Generator (entitygen) module and the basic pieces of the Common Application Components (commonapp) module.
The entitygen module represents a first round attempt using JSPs as templates to generate Java code (including Entity EJBs), SQL table creation code, XML deployment descriptors, and JSP user interfaces to manage entities defined in XML descriptor files which resemble the ejb-jar.xml deployment descriptor.
The commonapp module will eventually contain all of the core entities that any enterprise would likely need to run their business. At the moment it is only the frameword to support the code generated by entitygen. This includes a security framework, a caching framework, output formatting utilities, the web event handler (removes non-display logic from JSPs), and a basic user interface layout.