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 <andru..bjectstyle.org
>> > 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
>>>>
>>>>
>>>
>>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Sun Oct 25 2009 - 17:06:19 EDT