Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <6D780CA4-DC00-44FF-9C7D-8A8EAB1DC611@objectstyle.org>
From: Andrus Adamchik <andrus@objectstyle.org>
To: dev@cayenne.apache.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: DI-based configuration works
Date: Sun, 6 Dec 2009 18:20:37 -0500

An update on the new DI configuration... The new DI stack is now  
usable as a fully functional alternative to Configuration. I created  
an integration test module [1], showing how Cayenne can be started  
using the new approach. Actually it is as simple as that:

CayenneServerRuntime runtime = new CayenneServerRuntime(name.name());
ObjectContext context = runtime.newContext();

BTW "Server" in runtime name implies that we should be able to build a  
"Client" runtime for ROP stack in the future (actually should be quite  
easy). Configuration is done in a DI "module" class. Here is a  
standard one that can be amended or partially overridden by the users  
- [2]. Some highlights:

* The new configuration provides all the same functionality as the old  
one (except for JNDI preferences hack, which will turn into a first  
class feature once CAY-1327 is implemented).

* The new configuration is using a single-domain format compatible  
with CAY-1318.

* The new configuration loads descriptors from uniquely named files,  
such as "cayenne-stackname.xml, so there's no more single cayenne.xml  
file, and less chance of odd naming conflicts between multiple jars.

* Rewrote a bunch of old configuration code, which is now so much  
cleaner, mainly due to the design with injection in mind. There are  
still some rough spots in the service definitions and some functions  
missing in DI that I'd like to have, but it fully works as is.

* Better project model representation. I finally separated  
configuration objects (DataDomainDescriptor, DataNodeDescriptor) from  
runtime objects (DataDomain, DataNode). This made the runtime code  
cleaner, and also opens possibilities for cleaner Modeler code  
(currently there are lots of hacks to "edit" runtime objects).

* Added a number of important pluggable abstractions [2], such as  
ResourceLocator.

* Performance... I didn't see any difference in application startup  
time on a simple app between the new and the old stack.

So the next step is to finish CAY-1318 (which is mainly about  
upgrading the old projects to the new format), and to do the switch to  
the new configuration. In terms of public API, I think that most of  
the classes in org.apache.cayenne.conf will have to go. There's no  
point in deprecating them (although I sort of did it in a few places  
already), as the framework will not use them at all. One possible  
interim step is moving all these classes from runtime jars to the  
Modeler, so that the Modeler could read older project files and  
perform needed upgrades. At a later point we may also refactor the  
Modeler to use the new configuration classes, as mentioned above.

Also there's more work to be done to align the new config with the  
current config expectations (such as a singleton configuration... what  
do you think, do we need to keep it?? , provide an analog of  
FileConfiguration, etc.)

Andrus


[1] http://fisheye6.atlassian.com/browse/cayenne/trunk/itests/cayenne-di-stack

[2] http://fisheye6.atlassian.com/browse/cayenne/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/configuration/CayenneServerModule.java?r=HEAD&content=true