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 : Wed Jun 03 2009 - 07:43:31 EDT