I've been pondering on how a Cayenne IoC "bridge" might work. My
initial idea was something like an inverted "commons-logging". Spring/
Guice/Tapestry users would explicitly bind a Cayenne stack to a
respective container using some "binder" class that we provide,
specific to each container (unlike commons-logging that tries to guess
the environment, causing occasional grief). In the absence of an
external container Cayenne will use a very simple bundled container,
essentially a map of interfaces vs services loaded from a classpath
file.
There's also a JSR-330 that aims at standardizing injection annotations:
http://www.infoq.com/news/2009/08/dependency-injection-javaee6
And I just discovered that both Spring (3.0RC1) and Juice (trunk)
support the annotations from this JSR. So it could make sense for us
to use these annotations internally as well. Couldn't dig any info on
the Tapestry IoC support for this JSR, but they are on the JSR
"support group", so at least they are watching it.
Anyways, will need to experiment with it a bit and see how easy it is
to redefine internal Cayenne "services" from the application.
Andrus
On Jun 3, 2009, at 3:02 PM, Andrus Adamchik wrote:
Right... I envision lots of trouble integrating this into regular
JEE ecosystem. My current idea is to use built-in container only if
an app has no other container, and load Cayenne configs via an app
container otherwise, so that there's only one configuration registry.
Andrus
On Jun 3, 2009, at 2:42 PM, Malcolm Edgar wrote:
One concern I have about introducing a 3rd party IoC container is
class loader conflicts which may occur with including a popular IoC
container. As Cayenne may have a dependency on version X but the
application uses version Y.
regards Malcolm Edgar
On Wed, Jun 3, 2009 at 6:03 AM, Andrus Adamchik <[email protected]
> wrote:
I have a good opinion about Tapestry IoC approach in general
(including the
now defunct Hivemind), and I wanted to investigate Guice.
There's some conflicting requirements to address here - we don't
want to
write/maintain our own IoC container, yet, we don't want to embed
a huge
third-party engine, of which we'll use only a subset of features.
I'd like
it to work standalone, as well as be able to integrate (or at
least play
well) with popular IoC containers (how many containers in one app
is too
many?). Then there's a matter of modeler support, which is adverse
to
annotations, and favors XML or other config files...
All in all, I think assembling a core of Cayenne stack via such a
container
should open some interesting possibilities, beyond organizing
current
configuration.
Andrus
On Jun 2, 2009, at 6:53 PM, Robert Zeigler wrote:
If you're really considering going the 3rd party ioc route, I
highly
recommend T5IOC.
Note that configuration is (typically) done via code in T5IOC,
but I find
it extremely flexible & powerful, while still being simple to use
(and
small! :).
If not that, then guice. I'd even go for pico (though preferably
not).
Anything but the monster that spring has become. ;)
Robert
On Jun 2, 2009, at 6/29:02 AM , Andrus Adamchik wrote:
On Jun 2, 2009, at 4:38 PM, Andrus Adamchik wrote:
Modeler support will be covered by setting class name of
strategy
I am afraid this approach will be rather arbitrary to the end
user, so I
suggest we discuss it some more before putting it in Cayenne.
Marking an
entity to use "soft delete" based on some criteria is a clear and
understandable feature. Setting a "delete strategy" is not, and
will
contribute to confusion. This is totally be ok as a backend
extension point,
but I will hate to see that as a general use feature.
In this context let me mention one idea for Cayenne 3.0 + N,
that I've
been thinking about for some time. I am taking this to a
separate thread to
avoid distraction from the soft delete discussion, which has
only tangential
relevance.
Since we already have a bunch of extension points throughout the
stack,
some exposed via the Modeler (misplaced like cache JGroups
config, or
justified like Adapter config), and some are available only via
the code, we
need a way to reign them in. The standard way of doing that is
via an IoC
container.
No, I don't want to bundle Spring with Cayenne, besides it has to
integrate with the larger app ecosystem, so we still need to
figure the
technical details. But the point is that we will be able to
provide a single
place to configure all extension points, separate from the
mapping. As
unlike the mapping those parameters are often different for the
same
project, depending on the environment where it is deployed.
Right now this place is cayenne.xml (and it might as well stay
this way
in the future), just that unlike say Spring config files, it has
a rigid
structure and is not generic enough to handle arbitrary
extensions and
dependencies. It was ok for the early versions of Cayenne, since
there was
only a few things you could change (data source factory and
adapter I
believe). But now something more powerful and clean is desirable.
Just some raw thoughts.
Andrus
