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 >> >> > >
