cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: DI-based configuration works
Date Sun, 06 Dec 2009 23:26:52 GMT
Forgot one more important new feature:

* Any Cayenne extensions provided by users in the XML (custom  
DbAdapters, DataSourceFactories, etc) are passed through an injector  
on creation, so they don't have to rely on app-specific kludges to  
obtain various environment services (e.g. ResourceLocator). So you can  
do something like this:

class MyDataSourceFactory implements DataSourceFactory {

   private ResourceLocator resourceLocator;

   private SomeofMyOnwServices service1;



On Dec 6, 2009, at 6:20 PM, Andrus Adamchik wrote:

> 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(;
> 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]
> [2]

View raw message