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 {
@Inject
private ResourceLocator resourceLocator;
@Inject
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
