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 {
..nject
private ResourceLocator resourceLocator;
..nject
private SomeofMyOnwServices service1;
...
}
Andrus
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(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
>
>
This archive was generated by hypermail 2.0.0 : Sun Dec 06 2009 - 18:27:25 EST