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
This archive was generated by hypermail 2.0.0 : Sun Dec 06 2009 - 18:21:13 EST