First it is / would be possible to just replace all the wireing descriptors to spring configurations as the most ( all?!) of the IoC DI containers use external descriptors. There is a central point ( the servlet) where a single direct reference to hivemind will be hard coded just to access the first reference to the hivemind managed modules. Every servlet in the container is a subtype of an Basic abstract servlet class which has a abstract method to obtain the first reference. If you wanna switch to another IoC container the replacement of the servlet in the web.xml file should be sufficient. All the external jar / libs like the caucho WS impl. are also integrated in Spring (not sure about pico but it won't be a problem). So except of the meta data work people would have to do it is just a replacement e.g reimplementation of a single method.
Instead of Registry.getService() it would be ApplicationContext.getBean() is it that what you are alluding to? Yesterday I checked out the ASF third party licensing policy... The lists below declare which licenses are authorized and which licenses are excluded from applying to any part of a product distributed by an ASF PMC. Authorized: * Apache License 2.0 * ASL 1.1 * BSD * MIT/X11 * NCSA * W3C Software license * X.Net * zlib/libpng Binary only: * CDDL 1.0 * CPL 1.0 * EPL 1.0 * IPL 1.0 * MPL 1.0 and MPL 1.1 * SPL 1.0 So hivemind (requieres some other jars like javaassist it MPL and apache oro is ASF) is ASF, Easymock is MIT, the caucho Hessian WS is ASF. So keep on downloading these libs for a build but it won't be a problem to include these distributions inside a gdata distribution. best regards Simon On 11/9/06, peter royal <[EMAIL PROTECTED]> wrote:
On Nov 8, 2006, at 11:43 AM, Simon Willnauer wrote: > That's why I evaluated some IoC DI container like spring, hivemind, > pico and Felix (Apache OSGi). Hivemind felt good to me due to some > reasons (some more on this later @siren I will send a separate email > on this topic). would it be possible to fashion the GData server such that it is a set of POJO's (one logical module), and then there is another logical module that wires them up in a usable fashion using Hivemind (another logical module). That way if someone wanted to use pico/spring/ whatever, they could, since the core components are container- independent. since HiveMind services are POJO's, this should be possible, as long as no hivemind magic is required for the system to function. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
