You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2009/12/07 00:20:37 UTC
DI-based configuration works
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
Re: DI-based configuration works
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
>
>
Re: DI-based configuration works
Posted by Andrus Adamchik <an...@objectstyle.org>.
Done. The builds are noticeably faster now.
On Dec 9, 2009, at 4:52 AM, Andrey Razumovsky wrote:
> +1 for removing them all. I still can't get itests working on Windows
>
> 2009/12/9 Andrus Adamchik <an...@objectstyle.org>
>
>>
>> On Dec 8, 2009, at 5:24 PM, Aristedes Maniatis wrote:
>>
>> Since I've never used JPA I'm hazy on exactly what that means. For
>>> example, isn't EJBQL part of the JPA? I assume you aren't
>>> suggesting that
>>> goes away? Which bit of the implementation is in the JPA jars?
>>>
>>
>> Our JPA implementation was designed as a spec-compliant wrapper
>> around
>> Cayenne core. So JPA modules themselves are rather thin and contain
>> the
>> bridging code, and peeling off this layer will be transparent to
>> everybody
>> (except that the trunk will build faster). All the actual
>> functionality is
>> in cayenne-jdk1.5-unpublished module (including EJBQL), and of
>> course will
>> not be removed. Specifically these modules will be removed:
>>
>> * framework/cayenne-agent
>> * framework/cayenne-jpa-unpublished
>> * itests/jpa-chapter2
>> * itests/jpa-chapter3
>> * itests/jpa-chapter4
>> * itests/jpa-chapter5
>> * itests/jpa-chapter6
>> * itests/jpa-chapter9
>>
>> Andrus
>>
>>
>>
>
>
> --
> Andrey
Re: DI-based configuration works
Posted by Andrey Razumovsky <ra...@gmail.com>.
+1 for removing them all. I still can't get itests working on Windows
2009/12/9 Andrus Adamchik <an...@objectstyle.org>
>
> On Dec 8, 2009, at 5:24 PM, Aristedes Maniatis wrote:
>
> Since I've never used JPA I'm hazy on exactly what that means. For
>> example, isn't EJBQL part of the JPA? I assume you aren't suggesting that
>> goes away? Which bit of the implementation is in the JPA jars?
>>
>
> Our JPA implementation was designed as a spec-compliant wrapper around
> Cayenne core. So JPA modules themselves are rather thin and contain the
> bridging code, and peeling off this layer will be transparent to everybody
> (except that the trunk will build faster). All the actual functionality is
> in cayenne-jdk1.5-unpublished module (including EJBQL), and of course will
> not be removed. Specifically these modules will be removed:
>
> * framework/cayenne-agent
> * framework/cayenne-jpa-unpublished
> * itests/jpa-chapter2
> * itests/jpa-chapter3
> * itests/jpa-chapter4
> * itests/jpa-chapter5
> * itests/jpa-chapter6
> * itests/jpa-chapter9
>
> Andrus
>
>
>
--
Andrey
Re: DI-based configuration works
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 8, 2009, at 5:24 PM, Aristedes Maniatis wrote:
> Since I've never used JPA I'm hazy on exactly what that means. For
> example, isn't EJBQL part of the JPA? I assume you aren't suggesting
> that goes away? Which bit of the implementation is in the JPA jars?
Our JPA implementation was designed as a spec-compliant wrapper around
Cayenne core. So JPA modules themselves are rather thin and contain
the bridging code, and peeling off this layer will be transparent to
everybody (except that the trunk will build faster). All the actual
functionality is in cayenne-jdk1.5-unpublished module (including
EJBQL), and of course will not be removed. Specifically these modules
will be removed:
* framework/cayenne-agent
* framework/cayenne-jpa-unpublished
* itests/jpa-chapter2
* itests/jpa-chapter3
* itests/jpa-chapter4
* itests/jpa-chapter5
* itests/jpa-chapter6
* itests/jpa-chapter9
Andrus
Re: DI-based configuration works
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 8/12/09 11:49 PM, Andrus Adamchik wrote:
> I been thinking about this step, and decided against moving o.a.c.conf
> to the Modeler. Instead I am going to create a separate new module
> cayenne-project-unpublished, implementing project saving/loading
> functionality with the Modeler use in mind. Once this is done, the
> Modeler and runtime can be switched to the new stack simultaneously, and
> o.a.c.conf and o.a.c.project removed from the runtime jars.
>
> IIRC Ari mentioned before that project saving functionality doesn't have
> to be in the runtime. This refactoring will do just that.
Nice. I like the idea of a separate library since if anyone wanted to write an alternative modeler in the future, or incorporate support into wolips or some other eclipse plugin, then this would be a simple interface to interact with writing the model.
The downside is that reading the model and writing the model will now be scattered across two different places.
> And one more issue - maintaining the JPA jars is becoming an issue with
> the new configuration work, as it uses the old API and will require
> special attention. Since we are not working on JPA, I suggest that we
> remove it from trunk. It will be preserved in Subversion on 3.0 branch
> in case somebody decides to resurrect it. Thoughts? Objections?
Since I've never used JPA I'm hazy on exactly what that means. For example, isn't EJBQL part of the JPA? I assume you aren't suggesting that goes away? Which bit of the implementation is in the JPA jars?
Ari Maniatis
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: DI-based configuration works
Posted by Michael Gentry <mg...@masslight.net>.
Right now my side-project uses the server JAR to read the model. I
have no need of writing the model back. I can imagine other people
might some day need to be able to read the model, too (like you said,
maven/ant tasks), so I want to make sure that is kept in mind.
Thanks!
mrg
On Tue, Dec 8, 2009 at 9:57 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Actually it may end up being merged into cayenne-modeler module at some
> point. My thinking was also that there is a faint possibility that somebody
> other than the modeler might need it (Maven/Ant tasks?).
>
> Andrus
>
> On Dec 8, 2009, at 9:51 AM, Andrus Adamchik wrote:
>
>> Reading projects will stay in cayenne-jdk1.5-unpublished
>> (o.a.c.configuration). So nothing is going to change on the user end.
>>
>> Reading/writing will go into this new module, imported by the Modeler. So
>> cayenne-project-unpublished will not be included in cayenne-server.jar or
>> cayenne-client.jar, but will be included in the Modeler assemblies, e.g.
>> CayenneModeler.app.
>>
>> Andrus
>>
>> On Dec 8, 2009, at 9:46 AM, Michael Gentry wrote:
>>
>>> I guess I'm confused as to where it will reside when published, then.
>>> You are talking about the Cayenne models (XML files) that need to be
>>> loaded by both the server and the modeler (does ROP need them, too?)
>>> and that need to be saved by the modeler, right?
>>>
>>> Thanks,
>>>
>>> mrg
>>>
>>>
>>> On Tue, Dec 8, 2009 at 9:41 AM, Andrus Adamchik <an...@objectstyle.org>
>>> wrote:
>>>>
>>>> It will be an "unpublished" module, and yes, only the Modeler will be
>>>> importing it now. I sort of like to keep things modular as long as it
>>>> doesn't create user confusion (which I think it doesn't in this case).
>>>>
>>>> Andrus
>>>>
>>>> On Dec 8, 2009, at 9:26 AM, Michael Gentry wrote:
>>>>
>>>>> Is creating a separate module needed or would that just add more
>>>>> confusion? Would there be yet another JAR that shows up in the Maven
>>>>> repository for people to have to decide what they want?
>>>>>
>>>>> Seems to me the server side needs to be able to load the model, but
>>>>> only the Modeler needs to be able to save.
>>>>>
>>>>> mrg
>>>>>
>>>>>
>>>>> On Tue, Dec 8, 2009 at 7:49 AM, Andrus Adamchik
>>>>> <an...@objectstyle.org>
>>>>> wrote:
>>>>>>
>>>>>> I been thinking about this step, and decided against moving o.a.c.conf
>>>>>> to
>>>>>> the Modeler. Instead I am going to create a separate new module
>>>>>> cayenne-project-unpublished, implementing project saving/loading
>>>>>> functionality with the Modeler use in mind. Once this is done, the
>>>>>> Modeler
>>>>>> and runtime can be switched to the new stack simultaneously, and
>>>>>> o.a.c.conf
>>>>>> and o.a.c.project removed from the runtime jars.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: DI-based configuration works
Posted by Andrus Adamchik <an...@objectstyle.org>.
Actually it may end up being merged into cayenne-modeler module at
some point. My thinking was also that there is a faint possibility
that somebody other than the modeler might need it (Maven/Ant tasks?).
Andrus
On Dec 8, 2009, at 9:51 AM, Andrus Adamchik wrote:
> Reading projects will stay in cayenne-jdk1.5-unpublished
> (o.a.c.configuration). So nothing is going to change on the user end.
>
> Reading/writing will go into this new module, imported by the
> Modeler. So cayenne-project-unpublished will not be included in
> cayenne-server.jar or cayenne-client.jar, but will be included in
> the Modeler assemblies, e.g. CayenneModeler.app.
>
> Andrus
>
> On Dec 8, 2009, at 9:46 AM, Michael Gentry wrote:
>
>> I guess I'm confused as to where it will reside when published, then.
>> You are talking about the Cayenne models (XML files) that need to be
>> loaded by both the server and the modeler (does ROP need them, too?)
>> and that need to be saved by the modeler, right?
>>
>> Thanks,
>>
>> mrg
>>
>>
>> On Tue, Dec 8, 2009 at 9:41 AM, Andrus Adamchik <andrus@objectstyle.org
>> > wrote:
>>> It will be an "unpublished" module, and yes, only the Modeler will
>>> be
>>> importing it now. I sort of like to keep things modular as long as
>>> it
>>> doesn't create user confusion (which I think it doesn't in this
>>> case).
>>>
>>> Andrus
>>>
>>> On Dec 8, 2009, at 9:26 AM, Michael Gentry wrote:
>>>
>>>> Is creating a separate module needed or would that just add more
>>>> confusion? Would there be yet another JAR that shows up in the
>>>> Maven
>>>> repository for people to have to decide what they want?
>>>>
>>>> Seems to me the server side needs to be able to load the model, but
>>>> only the Modeler needs to be able to save.
>>>>
>>>> mrg
>>>>
>>>>
>>>> On Tue, Dec 8, 2009 at 7:49 AM, Andrus Adamchik <andrus@objectstyle.org
>>>> >
>>>> wrote:
>>>>>
>>>>> I been thinking about this step, and decided against moving
>>>>> o.a.c.conf to
>>>>> the Modeler. Instead I am going to create a separate new module
>>>>> cayenne-project-unpublished, implementing project saving/loading
>>>>> functionality with the Modeler use in mind. Once this is done, the
>>>>> Modeler
>>>>> and runtime can be switched to the new stack simultaneously, and
>>>>> o.a.c.conf
>>>>> and o.a.c.project removed from the runtime jars.
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: DI-based configuration works
Posted by Andrus Adamchik <an...@objectstyle.org>.
Reading projects will stay in cayenne-jdk1.5-unpublished
(o.a.c.configuration). So nothing is going to change on the user end.
Reading/writing will go into this new module, imported by the Modeler.
So cayenne-project-unpublished will not be included in cayenne-
server.jar or cayenne-client.jar, but will be included in the Modeler
assemblies, e.g. CayenneModeler.app.
Andrus
On Dec 8, 2009, at 9:46 AM, Michael Gentry wrote:
> I guess I'm confused as to where it will reside when published, then.
> You are talking about the Cayenne models (XML files) that need to be
> loaded by both the server and the modeler (does ROP need them, too?)
> and that need to be saved by the modeler, right?
>
> Thanks,
>
> mrg
>
>
> On Tue, Dec 8, 2009 at 9:41 AM, Andrus Adamchik <andrus@objectstyle.org
> > wrote:
>> It will be an "unpublished" module, and yes, only the Modeler will be
>> importing it now. I sort of like to keep things modular as long as it
>> doesn't create user confusion (which I think it doesn't in this
>> case).
>>
>> Andrus
>>
>> On Dec 8, 2009, at 9:26 AM, Michael Gentry wrote:
>>
>>> Is creating a separate module needed or would that just add more
>>> confusion? Would there be yet another JAR that shows up in the
>>> Maven
>>> repository for people to have to decide what they want?
>>>
>>> Seems to me the server side needs to be able to load the model, but
>>> only the Modeler needs to be able to save.
>>>
>>> mrg
>>>
>>>
>>> On Tue, Dec 8, 2009 at 7:49 AM, Andrus Adamchik <andrus@objectstyle.org
>>> >
>>> wrote:
>>>>
>>>> I been thinking about this step, and decided against moving
>>>> o.a.c.conf to
>>>> the Modeler. Instead I am going to create a separate new module
>>>> cayenne-project-unpublished, implementing project saving/loading
>>>> functionality with the Modeler use in mind. Once this is done, the
>>>> Modeler
>>>> and runtime can be switched to the new stack simultaneously, and
>>>> o.a.c.conf
>>>> and o.a.c.project removed from the runtime jars.
>>>>
>>>
>>
>>
>
Re: DI-based configuration works
Posted by Michael Gentry <mg...@masslight.net>.
I guess I'm confused as to where it will reside when published, then.
You are talking about the Cayenne models (XML files) that need to be
loaded by both the server and the modeler (does ROP need them, too?)
and that need to be saved by the modeler, right?
Thanks,
mrg
On Tue, Dec 8, 2009 at 9:41 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> It will be an "unpublished" module, and yes, only the Modeler will be
> importing it now. I sort of like to keep things modular as long as it
> doesn't create user confusion (which I think it doesn't in this case).
>
> Andrus
>
> On Dec 8, 2009, at 9:26 AM, Michael Gentry wrote:
>
>> Is creating a separate module needed or would that just add more
>> confusion? Would there be yet another JAR that shows up in the Maven
>> repository for people to have to decide what they want?
>>
>> Seems to me the server side needs to be able to load the model, but
>> only the Modeler needs to be able to save.
>>
>> mrg
>>
>>
>> On Tue, Dec 8, 2009 at 7:49 AM, Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>>
>>> I been thinking about this step, and decided against moving o.a.c.conf to
>>> the Modeler. Instead I am going to create a separate new module
>>> cayenne-project-unpublished, implementing project saving/loading
>>> functionality with the Modeler use in mind. Once this is done, the
>>> Modeler
>>> and runtime can be switched to the new stack simultaneously, and
>>> o.a.c.conf
>>> and o.a.c.project removed from the runtime jars.
>>>
>>
>
>
Re: DI-based configuration works
Posted by Andrus Adamchik <an...@objectstyle.org>.
It will be an "unpublished" module, and yes, only the Modeler will be
importing it now. I sort of like to keep things modular as long as it
doesn't create user confusion (which I think it doesn't in this case).
Andrus
On Dec 8, 2009, at 9:26 AM, Michael Gentry wrote:
> Is creating a separate module needed or would that just add more
> confusion? Would there be yet another JAR that shows up in the Maven
> repository for people to have to decide what they want?
>
> Seems to me the server side needs to be able to load the model, but
> only the Modeler needs to be able to save.
>
> mrg
>
>
> On Tue, Dec 8, 2009 at 7:49 AM, Andrus Adamchik <andrus@objectstyle.org
> > wrote:
>> I been thinking about this step, and decided against moving
>> o.a.c.conf to
>> the Modeler. Instead I am going to create a separate new module
>> cayenne-project-unpublished, implementing project saving/loading
>> functionality with the Modeler use in mind. Once this is done, the
>> Modeler
>> and runtime can be switched to the new stack simultaneously, and
>> o.a.c.conf
>> and o.a.c.project removed from the runtime jars.
>>
>
Re: DI-based configuration works
Posted by Michael Gentry <mg...@masslight.net>.
Is creating a separate module needed or would that just add more
confusion? Would there be yet another JAR that shows up in the Maven
repository for people to have to decide what they want?
Seems to me the server side needs to be able to load the model, but
only the Modeler needs to be able to save.
mrg
On Tue, Dec 8, 2009 at 7:49 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> I been thinking about this step, and decided against moving o.a.c.conf to
> the Modeler. Instead I am going to create a separate new module
> cayenne-project-unpublished, implementing project saving/loading
> functionality with the Modeler use in mind. Once this is done, the Modeler
> and runtime can be switched to the new stack simultaneously, and o.a.c.conf
> and o.a.c.project removed from the runtime jars.
>
Re: DI-based configuration works
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 6, 2009, at 6:20 PM, Andrus Adamchik wrote:
> 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.
I been thinking about this step, and decided against moving o.a.c.conf
to the Modeler. Instead I am going to create a separate new module
cayenne-project-unpublished, implementing project saving/loading
functionality with the Modeler use in mind. Once this is done, the
Modeler and runtime can be switched to the new stack simultaneously,
and o.a.c.conf and o.a.c.project removed from the runtime jars.
IIRC Ari mentioned before that project saving functionality doesn't
have to be in the runtime. This refactoring will do just that.
And one more issue - maintaining the JPA jars is becoming an issue
with the new configuration work, as it uses the old API and will
require special attention. Since we are not working on JPA, I suggest
that we remove it from trunk. It will be preserved in Subversion on
3.0 branch in case somebody decides to resurrect it. Thoughts?
Objections?
Andrus