PicoContainer 1.0 beta 1 has been released.

Discussions

News: PicoContainer 1.0 beta 1 has been released.

  1. PicoContainer 1.0 beta 1 has been released. (62 messages)

    The PicoContainer team is proud to announce the release of the first beta of PicoContainer 1.0.

    PicoContainer is an embeddable container for type-3 Inversion of Control (IoC) components. It is delivered as a set of abstractions, a couple of instantiable containers, a few adaptors for hierarchies and (optional) lifecycle management as well as support classes. We genuinely believe this to be the logical conclusion of the IoC component model.

    Components:

    The component model (igoring our lifecycle support) is unencumbered by obligations of API. There is nothing to extend, nothing to implement and nothing to throw. The component model forces no obligations for XML meta-data on the developer or user of PicoContainer components. The design is so simple, that for very tightly coupled deployments, a developer could cherry pick components and embed them in their application without even importing let alone using anything from the org.picocontainer codebase.

    Diversity:

    From the abstractions, other container developers can build containers compatible and interoperable with PicoContainer. We encourage diversity of implementation as we are not building a single container. In terms of the PicoContainer deliverable, there are no external Jar dependancies, and no use of XML for component declarations. Along with the PicoContainer deliverable, there is a Technology Compatability Kit (TCK). This is in the form of the abstract JUnit test cases. A container developer can use this to ensure than their implementation of a PicoContainer is compatible with the design. Container developers may choose from-scratch designs, wrapping of existing classes, or extending existing classes.

    NanoContainer:

    As a sister project to PicoContainer, we also have NanoContainer. Like PicoContainer, NanoContainer is more than one container. All are built to the PicoContainer design, and offer different embeddable visions. One interoperates with Nanning (the aspect framework) to provide aspect capability for arbitary components. Another retrofits JMX compatability to arbitary components. Some of the NanoContainers deliver component assembly and configuration via XML.

    The Plan:

    The plan is to build more containers and to sell the component design further.

    - The PicoContainer team.

    Visit www.picocontainer.org

    Threaded Messages (62)

  2. You might want to throw in the link to http://www.picocontainer.org with this story...
  3. Do you mean a link to http://www.picocontainer.org like this one?
  4. Is the new release changing the technical comparaison that Ron
    described on the spring web-site at :

    http://www.springframework.org/docs/lightweight_container.html

    Rgds,Claude
  5. Is the new release changing the technical comparaison that Ron

    > described on the spring web-site at :

    The arguments in the article by Rod and me that you've mentioned still apply. You may already have noticed that there's a P.S. that discusses the introduction of a bean-style factory as of PicoContainer 1.0 alpha2. But note that PicoContainer's focus is still on the constructor-based approach.

    A central issue is that we believe that you need to be able to configure a specific instance for a component dependency. For example, you might have 2 DataSource instances with 2 DAOs. Each DAO has a DataSource dependency, but each needs a specific one of the DataSource references. As far as we see, PicoContainer does not support this but assumes one instance per interface at runtime, to be able to adhere to its configuration-less "Type 3 IoC" dogma.

    Furthermore, you will need to configure String/int/etc parameters of your components, to avoid the repetitive parsing of properties files or the like. Spring's bean configuration approach solves this very elegantly. For this and the wiring up with specific instances of other components, one needs some kind of metadata. Spring makes this pluggable but offers a simple XML bean definition format as default choice.

    PicoContainer's argument that the one-constructor approach enforces the resolution of all dependencies is debatable too. Many components have optional dependencies and can be used nicely without explicitly specifying them, especially regarding String/int/etc parameters with default values. Spring's bean-style approach doesn't constrain this in any way. As a side effect, this also makes the components more flexible when used outside a container.

    Juergen
  6. PicoContainer's argument that the one-constructor approach enforces the resolution of all dependencies is debatable too.

    A container that discourages lazy processing is sure to suffer poor performance under load.
  7. Hi all !

    Regarding the use of constructors... I personnally don't like constructors parameters much, because I understand their semantics like this: setup the object initial state, once and for good.

    Here are some problems that quickly occur with the use of constructor params everywhere :
    - you can't reuse instances in a different context, since parameters are fixed at creation time
    - you must have an object tree, graphs are forbidden: no object sharing. Otherwise, you'll risk cycles ! And constructors don't allow for cycles ! eg: object A requires B and C, and C requires A...
    - you must have one constructor per set of parameters... Some instances may require objects B and C, others only C, and passing nulls is often not a solution (unreadable among other problems)

    I used to work on a framework allowing a lot of flexibility to construct objects graphs declaratively: Kilim, hosted by http://www.objectweb.org/
    And we encountered these problems, and solved them through flexibility : allow every possible situation... which makes the framework quite complex.

    But imho, the constructor-only approach is the most limiting... Think about it: no sharing, no flyweight... very limiting ! One size does not fit all.

    I think that constructors' parameters semantic should be clear in a group of developers, to avoid different programming styles. For instance, you could agree that constructor parameters are immutable (no associated public setter). This ensures the semantics of the parameter: initial state. Another use they have is for composition (UML definition): in fact, I wonder if this is not the only case where it's good to have them.
    If you have public setters for your constructor's params, you'll soon see "initialize()" methods called in your setters :-) And your setters will have loads of side effects, really tough to debug, and you'll have to deal with the sequence of calls to setters... good luck (yes, I've seen that :-)
    Guess why Eclipse mandates to pass the parent via the constructor of SWT components: because the parent is immutable, and the relationship is a composition. Swing uses parent.add(child), and must check a component is not added twice...

    Just my humble opinion... which I enforce in my teams :-)

    Chris
  8. Hi Christophe.

    "you can't reuse instances in a different context, since parameters are fixed at creation time"

    Correct. But you can reuse them in the same context. If you start reusing in different context, you're doing singletonish stuff, which I consider a bad practice. Nothing in PicoContainer stops you from doing this though. You can just put a setXxx(Xxx xxx) method on your component and use the component multicaster to set some shared Xxx on them all.

    "you must have an object tree, graphs are forbidden: no object sharing. Otherwise, you'll risk cycles ! And constructors don't allow for cycles ! eg: object A requires B and C, and C requires A..."

    Correct. I believe that systems with cyclic dependencies are subject to code smell. Cyclic dependencies are never needed, as they can always be normalised to non-cyclic graphs by introducing a mediator object in between. A<->B becomes A->C<-B.

    "you must have one constructor per set of parameters... Some instances may require objects B and C, others only C, and passing nulls is often not a solution (unreadable among other problems)"

    Correct. And I believe that classes/components with multiple constructors are smelly too. Consider this:

    public class Fridge {
       private Socket socket;

       public Fridge(Socket socket) {
          this.socket = socket;
       }

       public Fridge() {
          // BAD. Leaves object in unusable state.
          this.socket = null;

          // BAD. Violates IoC by creating refs ourself.
          this.socket = new Socket();
       }

       public void connect() {
          socket.blah();
       }
    }

    Although a programming language allows you to have multiple constructors, it is bad to do so for at least two reasons:
    1) Users are unsure which ones to use.
    2) You might end up creating objects in unusable states. new Fridge().connect() will fail.

    So relying of setters to fullfil a dependency contract leaves an object in an inconsistent state until all the setters are called. With one constructor you know that when an object is created, it is always in a consistent state.

    So while you might argue that PicoContainer enforces some coding practices, we believe all of these encourage a better design of your system. Not being able to reuse instances, have cyclic dependencies or multiple constructors isn't really a problem. Systems without these characteristics are generally easier to understand and maintain. No real loss.
  9. So relying of setters to fullfil a dependency contract leaves an object in an inconsistent state until all the setters are called.


    So you're enforcing a dependency contract via a constructor? If you are requiring a contract, why not enforce it through an interface? I understand that an interface would force changes into the codebase, but then again, so does requiring a constructor, but without the advantages of compile-time checking against that contract.

    I don't think you can have it both ways. You can't claim that a component container has zero impact on existing components because it doesn't force interfaces and then turn around and require certain constructors. I don't know that I'll every be a big fan of using something like Pico because I don't like awkward constructors. If something is going to be non-intrusive, it should be non-intrusive.

    As for Spring, I realize that they don't require constructors because they set bean properties. But I think I'm missing something. Because if the point is to use the lightweight framework because it doesn't intrude, you still have to pepper your code with Spring-specific calls out to the BeanFactory to get at spring-registered components. So your code is dependent on Spring already. I suppose it's only your client code, but how does it deal with dependencies in your service code (service code referring to the code inside the things that spring serves up to you)?

    Again, I may be missing something, and I agree with Juergen when he says that there is no documentation on how to use Spring as a standalone container. Personally, I'm using more of a registry concept similar to the HiveMind thing (similar based on what I know about it). I've had a lot of success with it. It DOES force an interface on things, IService, but that's because I only use it to register services that should accessed universally that I don't want to limit to singletom access and whose configuration I want to be able to tweak without recompilation. Interestingly, what I'm using is HEAVILY based on what I got out of Rod Johnson's J2EE book, without the "bean" genericity. Excellent book by the way. I realize that forcing IService may offend the IoC zealots but if my code is going to have to provide a way to get at registered services (I use a "ServiceProvider" instead of a "BeanFactory"), then I'm already dependent anyway. Forcing an interface in this case gives me better type checking and allows for lifecycle events. I have an abstract service that I inherit from that takes care of the (relatively simple) plumbing and it's thus easy to write new services. I don't need HiveMind's dependency checking so I don't implement it.
  10. Drew,

    > As for Spring, I realize that they don't require constructors because they set bean properties. But I think I'm missing something. Because if the point is to use the lightweight framework because it doesn't intrude, you still have to pepper your code with Spring-specific calls out to the BeanFactory to get at spring-registered components. So your code is dependent on Spring already. I suppose it's only your client code, but how does it deal with dependencies in your service code (service code referring to the code inside the things that spring serves up to you)?

    A Spring application context wires up all the beans that make up your business and data access layers. The interconnection works purely via bean references, so typically no business or data access object has to be aware of the application context for manual lookup or the like. Everything works via bean references, passed to exposed bean properties.

    It's true that clients of your business layer have to look up the respective beans in the application context, be it a Struts action, a JUnit test case, or a desktop GUI listener. This only affects your business facades though, typically just a small subset or the beans that make up your middle tier.

    If using Spring's web MVC for the web tier, your web controllers can get wired up with your Spring-managed business facades in the same way as the middle tier. So in a Spring web app, you typically don't need a single manual bean lookup. The "lightweight container" article illustrates this with sample context definitions for both middle and web tier.

    If leveraging Spring's remoting support, you can even expose remote services in simple ways, without having to code any manual bean lookup. Spring's pre-built service exporters for Hessian, Burlap, and transparent RMI can take a plain business bean with a business interface and expose it as remote service. All of the 3 mentioned tools do not require any marker interfaces or specific exceptions to be declared.

    Juergen
  11. Multiple constructors[ Go to top ]

    Aslak:
    Although a programming language allows you to have multiple constructors, it is bad to do so for at least two reasons:
    1) Users are unsure which ones to use.


    Then it's your fault for not documenting your constructors properly.


    2) You might end up creating objects in unusable states. new Fridge().connect() will fail.


    Then it's your fault for implementing buggy constructors.

    I don't follow your point, Aslak. Just because sometimes, the two problems mentioned above happen, you jump to the conclusion that "All classes with multiple constructors are bad".

    Sounds like excessive generalization to me.

    Not being able to reuse instances, have cyclic dependencies or multiple constructors isn't really a problem. Systems without these characteristics are generally easier to understand and maintain.

    Sure. And they can be even easier to understand if you disallow inheritance, and overloading, and...

    But by going this way, you are negating a lot of positive things that we have learned the hard way in programming languages these past twenty years.

    Seems strange to me.

    --
    Cedric
    http://beust.com/weblog
  12. Multiple constructors[ Go to top ]

    Cedric:

    I realise that it might seem handy sometimes to implement a class with multiple constructors. But I believe that the percieved handiness is a result of laziness. "Let's make a smaller constructor that takes less parameters, it's faster to write code that makes new Foo()s now".

    Joshua Bloch talks about good citizens. This is along the
    lines of the fail-fast idea that an object or component is never in an
    inconsistent state: just by existing it is ready to provide a service.
    So you don't get this constructor -> setters -> post setters model with
    a scary inconsistent bit in the middle - by the time the object is
    constructed it is ready to roll. In fact this leads to *less* defensive
    coding - you don't need to do state checks on objects you collaberate
    with, the objects themselves need far less internal consistency checks etc.

    If you're writing a component that is meant to be used in an IoC environment (no matter the type 1,2,3, no matter the container) AND be a good citizen, I believe there is only one way to set it up.

    Remember, IoC is often referred to as the "Hollywood pattern/principle". Don't call us, we call you.

    If your component is written in such a way that it can be configured to be a good citizen in many different ways, how does the IoC container (hollywood) know ho to configure you (what number to call)?

    Some IoC type 2 containers (based on setters) give the container hints about how to configure the component in (XML) settings.

    The inherent problem with multiple constructors from PicoContainer's perspective is exactly that. Which one to use. Of course, we could add some way to give the container hints about this, but since one of our primary goals is simplicity, we haven't done that yet.

    Cedric, you know that programmers make mistakes all the time. PicoContainer's component style removes two common sources of error. You're saying:

    "Then it's your fault for not documenting your constructors properly."
    and
    "Then it's your fault for implementing buggy constructors."

    Exactly! When you follow the single constructor pattern we advocate, you're less likely to do these errors! Two less sources of errors throughout your entire architecture is a good thing, not a bad one.

    Can you give me an example of an IoC component where multiple constructors would be needed? (I can't imagine one myself).

    Aslak
    http://blogs.codehaus.org/people/rinkrank/
  13. Multiple constructors[ Go to top ]

    Aslak:
    Can you give me an example of an IoC component where multiple constructors would be needed? (I can't imagine one myself).


    We are talking about business objects, here. And for having talked to numerous clients, it's just crazy what people do with "your" stuff. Trust me.

    The bottom line is: you just don't know what your customers will need and how they will decide to implement their objects, so it is very important to push as few restrictions as possible on them, or they will simply turn away.

    I use multiple constructors in Java all the time (I explained exactly how in a past weblog entry) and a framework that would force me to redesign my code around this would be a problem.

    I would also contend that with this restriction, you might also be encouraging people to write bad code in the sense that you are forcing them to collapse alltheir constructors in one big one with a big list of parameters, some of them will necessarily be null, hence leading to exactly the situation you are trying to avoid: an object that is not quite ready.

    Trying to enforce the fact that all objects within the container are in the "ready" state is laudable but I believe it can only be achieved with proper training, not syntactic limitations.

    --
    Cedric
    http://beust.com/weblog
  14. Multiple constructors[ Go to top ]

    I disagree rather strongly with your assertions about multiple constructors. Objects do not necessariy have a single starting state reflected by a single constructor - it's fairly common in very real medium-complexity domain models for key classes to have multiple valid initial states, and these are reflected by multiple constructors.

    Further - multiple constructors are often a great convenience when the same information can be created in multiple ways, or enter into a object lifecycle at varying points. Think of a socket which can be created via "(int port, Strin host)", or "InetAddress, port", or created unbound (and later bound via the bind() method). All three of these are valid, and the socket ends up in valid (albeit different) starting states.

    In fact, extending the socket example, it turns out you need the () constructor (unbound to a port) for sockets to deal with NIO channels.

    The bottom line is that many classes don't have one clear use - they may be designed to be flexible and be used in a variety of situations, and with different starting states depending on the needs of the developer.

    What you are saying - classes should have a single constructor only - implies that a given class can only have one starting state. And that's just plain silly.

        -Mike
  15. Multiple constructors[ Go to top ]

    When you follow the single constructor pattern we advocate, you're less likely to do these errors! Two less sources of errors throughout your entire architecture is a good thing, not a bad one.

    This is surely a boost for maintaining an object's invariants and simplifying its state model, since the initial state is a guaranteed ready state. Sessional component methods are surely also aided by virtue of newly constructed objects not needing further public stroking prior to service. Generally anything that helps consolidate an object's state model and public interface is a good thing. Simplicity is an architectural maxim.
  16. Multiple constructors[ Go to top ]

    \Brian Miller\
    Generally anything that helps consolidate an object's state model and public interface is a good thing. Simplicity is an architectural maxim.
    \Brian Miller\

    If you want to consider architecture, then you should take a higher level view than a single component or simple graph of components.

    In my own design and development experience, I've found attempting to use a single constructor complicates the calling code - sometimes significantly. This is especially true if you're employing factories, or have object links between parents and children.

    As I mentioned in my other post, there is rarely a single, clear cut use for a given class when you consider it from the perspective of a user of that class. This is particularly true when you consider the lifecycle of a large graph of objects. If you make your classes flexible, a slight increase in complexity in your base classes can make the code _using_ those classes much easier. The end result is that your overall code base is easier to understand and use. If you use a single-constructor approach, you can easily find yourself in a situation of bending over backwards trying to have a number of parameters available for an object's construction - at a time when it is unnatural or inconvenient.

    Indeed, in situations where you have circular references of one sort or another, it's common to have multiple life-cycle passes because that's the most natural and consistent way to order the initialization of a large graph.

    In very straightforward use this sort of thing never comes up, but when you start considering a group of cooperating classes, or using several APIs which are coordinated by your own code, or just a novel context that doesn't match "straightforward use", this sort of thing comes up repeatedly (as in the Channels vs. sockets example I referenced before). And when it does, it's infinitely easier to adapt a few individual classes to multiple initial states and constructors then it is to bend an entire object graph just to adhere to an inflexible rule (one constructor only!).

        -Mike
  17. Multiple constructors[ Go to top ]

    Hey, PicoContainer now supports multiple constructors (currently in CVS, will be in 1.0-beta-2).

    PciContainer will pick the largest satisfiable constructor (i.e. the one with most parameters).

    If more than one with equal number of parameters is found (and there are no other bigger ones), an Exception will be thrown.

    Happy now?
  18. FYI, it has to be noted that Spring offers a full-blown application framework, while PicoContainer is "just" a puristic IoC container. It's Spring's *bean container* that competes with PicoContainer. Spring includes the bean container, an AOP framework, an application context concept, generic transaction management, DAO support for JDBC/Hibernate/JDO, lightweight remoting, a web MVC framework, etc.

    Note that Spring is cleanly layered for maximum reusability. Most parts can be leveraged on their own in a library style *and* also work seamlessly within a Spring application context. Spring's approach is *not* comparable to an integrated application framework like Expresso. In contrast to the latter, Spring supports best-of-breed choices in many respects, e.g. for transaction strategies, persistence, remoting, and web MVC.

    We even offer 3 distinct jar files for 3 typical Spring usage scenarios:
    - "spring-beans" for the bean container and core utilities (just ~115 KB!)
    - "spring-jdbc" for use as data access and transaction library with bean container, AOP support, and EJB integration (~350 KB)
    - "spring-full" for use as full application framework with optional, sophisticated web support (~550 KB)

    Juergen
  19. I would say the flexibility of Spring is very impressive. And the simplicity of Pico is also impressive. I would like to see the combination of both. ie loading small robust pico containers as components in Spring....
  20. Is there any response to the Spring-Pico comparision at http://www.springframework.org/docs/lightweight_container.html (see section 5). I would like to hear what pico guys would say about these...

    Pico approach looks a lot cooler because pico container handles the dependencies and such with elegant constructor based solution (no xml.. clean) but Spring makes more sense to me so far after reading the comparision..
  21. Regarding "no configuration with Pico" resp. "no XML...clean": Have a look at the Pico Configuration section of their website. Obviously, there *has* to be some sort of metadata resp. some sort of configuration: Whether you apply it programmatically or by any other means is just a different way.

    Obviously, Pico *needs* configuration too, if just to register implementation classes for component interfaces, and strings/ints/etc for component implementation parameters. It is *not* true that Pico is configuration-free. This isn't surprising: An application cannot get wired up with no information at all, else the wiring would be so trivial that you don't need a container in the first place.

    Note that Spring offers a mechanism that is very similar to Pico's programmatic registration: programmatic registration of bean definitions via its StaticBeanFactory. XmlBeanFactory is just a different implementation of the same BeanFactory interface that applications see, so apps are *not* tied to the XML format in any way. The XML version is the recommended one though, as it preferable to keep such wiring up in metadata.

    A general difference to Pico is that Spring defines named component *instances* while Pico defines unnamed component *classes*. It is not possible with Pico to register 2 instances of the same class with different parameters, e.g. 2 DAOs that receive a different DataSource reference. This is a serious limitation of the whole model, not of Pico's current implementation. Spring adds the notion of bean names to be able to overcome this restriction.

    All things considered, Spring doesn't add any unnecessary metadata but just the simplest means that allow for the wiring up of named bean *instances*. The XML format in particular is very simple but also very flexible: You won't get any simpler than that without losing power. We are not talking about EJB-style bloated deployment descriptors here ;-)

    Juergen
  22. Spring compared to Avalon[ Go to top ]

    We are currently looking into different containers. We found Spring as well as Picocontainer, but Avalon seems to be the biggest player in this game.

    How does Avalon compare to Spring?

    Is there any comparison betweens these two (or three if you also include Picocontainer)?

    What are other alternatives?

    Thanks

    Stephan
  23. Spring compared to Avalon[ Go to top ]

    Avalon is definitely the oldest IoC container but not really big... It's basically just a set of interfaces for components and service managers, with various implementations in sometimes unclear states.

    For wiring up, every Avalon component needs to look up cooperating components via the Avalon ServiceManager, passed to automatically if it implements the Serviceable interface. This is very intrusive, as practically every application component with dependencies has to implement that Avalon interface. Furthermore, the lookup mechanism is based on the service interface. If you want to receive as specific instance, you have to use the ServiceSelector with a specific key, another special mechanism.

    Spring offers a completely non-intrusive approach for wiring up: Application beans just receive bean references via standard setter methods. So if a bean needs a DataSource, it just has to provide a setDataSource(DataSource) method. The bean container will call this method if the bean definition specifies a bean reference for the dataSource property. *Which* DataSource instance the bean will receive is determined by the bean factory, by default in the XML bean definition file.

    Another major difference between Avalon and Spring is that Avalon defines quite a lot of optional interfaces that a component can implement, like Startable, Stoppable, etc. Spring just offers InitializingBean and DisposableBean at the moment, mainly because there has not been demand for explicit start/stop cycles. Alternatively, one can also specify an "init-method" and/or "destroy-method" in the bean definition, so that a bean does not even have to implement a Spring-specific interface for such resource handling callbacks.

    Avalons's most important container implementation, Phoenix, targets standalone applications like full servers. Avalon has its advantages there, as it has been designed for start/stop cycles etc. The only stable implementation for embedded use like within a web application is Excalibur, which competes with Spring's bean container. Judging from the website and forum activity, Spring is much more actively developed. And of course, Spring's feature set is far beyond the bean container itself.

    All things considered, Spring offers a more elegant and less intrusive approach than Avalon/Excalibur for wiring up components. PicoContainer tries to address the intrusion problem too (that was one of its main incentives to depart from the Avalon project) but is limited to its one-constructor and one-instance-per-interface model. To the best of my knowledge, Spring is the only lightweight container with focus on bean properties for wiring up, and bean names for identifying specific instances.

    ---

    Finally, an example for the easy reuse of an existing bean. The following bean definition sets up a Jakarta Commons DBCP BasicDataSource in a Spring application context, with an example DAO that receives the dataSource via an expose setDataSource method:

      <bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property>
        <property name="url"><value>jdbc:mysql://localhost:3306/mydb</value></property>
        <property name="username"><value>root</value></property>
      </bean>

      <bean id="exampleDataAccessObject" class="example.ExampleDataAccessObject">
        <property name="dataSource"><ref bean="myDataSource"/></property>
        <property name="exampleParam"><value>someValue</value></property>
      </bean>

    With PicoContainer, you'd have to subclass BasicDataSource to give it one single constructor that takes all "necessary" parameters (is password or validationQuery necessary, for example?), and you would just be able to register one such instance for the DataSource interface (what if accessing 2 databases?).

    With Avalon, you'd have to subclass BasicDataSource too and make it implement Configurable (for the parameters) and Stoppable (for the close call). Furthermore, the example DAO would have to implement Serviceable to look up the DataSource, and use the ServiceSelector mechanism to choose one by some key if there were more than one.

    Juergen

    P.S.: Quite a lot of new thoughts and arguments - I guess I'll have to update the "lightweight container" article on the Spring website :-)
  24. Spring compared to Avalon[ Go to top ]

    My only problem with Spring is the "bean" nomenclature. I've always found the use of the word "bean" to be kind of goofy. It's based on a marketing-type naming convention from Sun that's since become terribly confused since EJBs showed up. The notion of a "bean" doesn't tell me anything, especially if I'm new to the language. Of course, I notice that Spring's "bean" configurations aren't specific to "components" but can actually include instances of any arbitrary object. Since those objects are acceptable to Spring because the follow the JavaBean standards, I guess we're stuck with "bean". Unfortunate. Colleagues of mine from the MS world have always mocked the "bean" and "JThis and JThat" naming so prevalent in Java.:)

    BTW, how does all of this compare with Howard Lewis Ship's "Hivemind" project? (another unfortunate victim of poor naming)
  25. Spring compared to Avalon[ Go to top ]

    HiveMind is a micro container for services, basically a service registry that allows to look up service singletons by id. Services and their "extension points" get defined in an own XML format. HiveMind also has interceptor support, basically AOP for services. As HiveMind services have to implement an (any) interface, it's easy enough to intercept them.

    HiveMind is *not* IoC-based by design, so there's hardly anything applied to the services from the outside. Instead, the services use HiveMind APIs to read their "extension points", i.e. to look up parameters or collaborating services. HiveMind is generally quite intrusive by design, it doesn't aim to configure application objects that aren't aware of being managed at all.

    So HiveMind is close to Avalon in that it forces the managed objects to implement container interfaces for configuration and wiring up. It is deliberately simpler than Avalon though, having far fewer callback interfaces, as it aims to be a service microkernel. In comparison with PicoContainer, I see hardly any overlap with the latter's purist IoC.

    A similarity to Spring is that HiveMind registers service instances by id and uses XML for service configuration. Note that XML configuration is just the *default* strategy with Spring: A Spring bean factory can also read bean definitions from e.g. a resource bundle. There are actual use cases for this, e.g. for localization of view definitions within Spring's web framework.

    An interesting notion of HiveMind is its "line precise error reporting": It stores the XML file line numbers for later reference on service instantiation. Tracking down configuration errors should be pretty easy then. Actually, this is one goal that Spring doesn't actively pursue but might in the near future. Such precise error reporting is definitely a productivity boost.

    All things considered, Spring covers the service registration and interceptor aspects of HiveMind *plus* the non-intrusive IoC aspects of PicoContainer, using its bean configuration approach as the simple, central metaphor. Both parametrization and wiring up with other services works via bean properties: One single concept for service configuration that proves very powerful.

    Juergen

    P.S.: As with Avalon too, I do *not* claim to have understood every detail of the respective framework. I've just tried to summarize the major design goals and their benefits and drawbacks. Feedback is welcome, of course, especially from actual users of those frameworks.
  26. HiveMind in the mix[ Go to top ]

    Hey, I like the name.

    > HiveMind is a micro container for services, basically a service registry that allows to look up service singletons by id. Services and their "extension points" get defined in an own XML format. HiveMind also has interceptor support, basically AOP for services. As HiveMind services have to implement an (any) interface, it's easy enough to intercept them.
    >
    > HiveMind is *not* IoC-based by design, so there's hardly anything applied to the services from the outside. Instead, the services use HiveMind APIs to read their "extension points", i.e. to look up parameters or collaborating services. HiveMind is generally quite intrusive by design, it doesn't aim to configure application objects that aren't aware of being managed at all.

    I'm having trouble tracking down an accurate definition of IoC. To me, it means that the component/service/object is instantiated from outside, and is configured from outside ... the outside being some for of container.

    Using HiveMind and the BuilderFactory, you can do very, very IoC things using HiveMind (as long as you are willing to accept that services are singletons, pooling will come later).

    HiveMind uses properties, must like Spring framework (which I've just glanced at), so the objects aren't "aware" of being configured (that is, they don't have to implement any kind of interface), but the developer must describe, in the HiveMind module deployment descriptor (say that six times fast) what the configuration is ... the class to instantiate, which properties to set (some of which may be services or extension point element lists).


    The examples I've been creating (at work) are very simple and very testable. The final implementations are simple JavaBeans, easy to create and configure inside a unit test.

    >
    > So HiveMind is close to Avalon in that it forces the managed objects to implement container interfaces for configuration and wiring up. It is deliberately simpler than Avalon though, having far fewer callback interfaces, as it aims to be a service microkernel. In comparison with PicoContainer, I see hardly any overlap with the latter's purist IoC.

    Again, services are interfaces; implementations are secondary and often brewed up on the fly using Javassist. IoC is used, with an escape clause (there is a single, optional callback interface).

    What's neat is that HiveMind is already feeding on itself, with new core features (such as service proxies) being implemented using existing services (hivemind.ClassFactory).

    >
    > A similarity to Spring is that HiveMind registers service instances by id and uses XML for service configuration. Note that XML configuration is just the *default* strategy with Spring: A Spring bean factory can also read bean definitions from e.g. a resource bundle. There are actual use cases for this, e.g. for localization of view definitions within Spring's web framework.
    >

    HiveMind has a localization stategy where every module may have localized bundle of message properties, and these values are easily accesible in code, or in the descriptor. I borrowed some syntax from Eclipse.


    > An interesting notion of HiveMind is its "line precise error reporting": It stores the XML file line numbers for later reference on service instantiation. Tracking down configuration errors should be pretty easy then. Actually, this is one goal that Spring doesn't actively pursue but might in the near future. Such precise error reporting is definitely a productivity boost.
    >

    I created this initially for Tapestry back in January while I was working on example code for the Tapestry book; my personal productivity skyrocketted ... it's just amazing what happens when your errors are identified down to the file and line. It's not magic ... just a little discipline.


    > All things considered, Spring covers the service registration and interceptor aspects of HiveMind *plus* the non-intrusive IoC aspects of PicoContainer, using its bean configuration approach as the simple, central metaphor. Both parametrization and wiring up with other services works via bean properties: One single concept for service configuration that proves very powerful.

    I think people are missing some of the more powerful concepts in HiveMind.

    First off, HiveMind is basically the Eclipse plugin model with services tacked on.

    That means that modules define extension points and other modules plug into those extension points by contributing XML.

    Eclipse uses this kind of thing to populate menu bars and context menus and hundreds of other things; its a well proven (by Eclipse) approach.

    My day job, at WebCT, involves an application of vast scale that will, gradually, convert from ad-hoc XML parsing and an over-reliance on EJBs into a collection of HiveMind modules, services and extension points. Some services will be proxies to EJBs.

    The point of HiveMind is to avoid the ugly, buggy, ad-hoc configuration coding and other bits that get in the way of writing solid, testable, flexible code. So, HiveMind takes those XML contributions and converts them into Java objects, using rules you specify (a limited form of Jakarta Digester).

    Looking at Pico; it appears that if service A uses service B, then when you instantiate service A it must also instantiate service B, to that B can be passed to A's constructor. There's also the issue of how service A and B can work together (you can only construct one object at a time).

    HiveMind hides services behind interfaces; this means that a proxy to B can be set as a property of A. The proxy will force the creation of B (the core implementation and interceptor stack) just-in-time; A doesn't know or care because the proxy implements the service interface and behaves just like the real implementation.

    I noticed in the example Merlin (Avalon) code, that services that used other services needed to do a little lookup. To me, that's way more work to get good code coverage ... having to check for null, lookup the object, maybe synchronize the whole method. With HiveMind, you get an implementation of the service and you're done ... all the just-in-time stuff is handled behind the scenes.

    Similar stuff goes on with extension points, which are represented as lists of Java objects; the XML-to-object conversion occurs only as needed, hidden behind a List proxy.
  27. HiveMind in the mix[ Go to top ]

    Oh, I don't mind the name that much, i suppose. Just sounds sort of creepy to me, like I'll be assimilated if I use it.

    I have nothing against the project, though. As soon as things settle down, I'd like to investigate it more. It seems similar in approach to a home-grown thing I've been using but with more power. I'd be more than happy to gut my service registry and replace it with something better. Same goes for Spring, or Pico. Though again, hate to bash it, but Pico seems to offer the least, at the expense of "non-intrusiveness" that I don't really think it offers (because of the need to enforce a service contract via constructors).

    PS
    I've never been mentioned by name in someone's blog before. Though I did get referred to once in the BileBlog from a post I made on the webwork lists....
  28. IoC definition[ Go to top ]

    Howard:
    I'm having trouble tracking down an accurate definition of IoC. To me, it means that the component/service/object is instantiated from outside, and is configured from outside ... the outside being some for of container.


    The best way to understand IoC is to think of it as "abstract methods for containers".

    But IoC advocates usually don't like this definition because suddenly, everybody can understand it :-)

    --
    Cedric
    http://beust.com/weblog
  29. IoC definition[ Go to top ]

    The best way to understand IoC is to think of it as "abstract methods for containers".

    >
    > But IoC advocates usually don't like this definition because suddenly, everybody can understand it :-)
    >
    > --
    > Cedric
    > http://beust.com/weblog

    I think that's a bit off... None of Spring, Picocontainer, nor XWork IoC require container-specific interfaces or methods. Not like some containers *cough* *EJB* *cough*.

    Think of it as "the container builds my objects and wires them up with everything they need while it's at it".
  30. IoC definition[ Go to top ]


    > > But IoC advocates usually don't like this definition because suddenly, everybody can understand it :-)


    I think that's a bit off... None of Spring, Picocontainer, nor XWork IoC require container-specific interfaces or methods. Not like some containers *cough* *EJB* *cough*.

    See what I mean?

    --
    Cedric
    http://beust.com/weblog
  31. IoC definition[ Go to top ]

    More seriously now...

    Jason, you are taking my answer too literally. I wasn't speaking of implementing abstract methods sensu stricto but just trying to illustrate the concept.

    An IoC container gives you some extension points allowing the user to plug-in their own domain-specific implementations. This is exactly similar to the concept of abstract methods.

    --
    Cedric
    http://beust.com/weblog
  32. IoC definition[ Go to top ]

    Cedric,

    I think you're confusing the issue with language like "extension points" and "plug-in their own domain-specific implementations". This makes it sound like I'm actually extending some base class or something.

    With an IoC container, I can program the way that seems natural, without having to worry about how everything gets wired together. I first define a service interface, then an implementation, all from scratch with no base class or other interfaces required. I configure the container to know about this service and implementation somehow (much of the discussion in this thread is about how this is done). Now, I have objects which are instantiated and wired up by the IoC container (how this wiring is done is the other part of this conversation). Presto! I have bits of reusable logic wired to other bits of reusable logic all written as POJO's with no registry lookup, etc. I have simple code which is simple to test (pass in a Mock of the service interface and unit testing is easy) and simple to decompose into separate services.

    I could postulate that EJB container vendors like to muddy the waters about lightweight containers so people DON'T understand :-)

    Jason
  33. IoC definition[ Go to top ]

    No, Cedric is right. Abstract methods are for inheritance what IoC is for frameworks: Your code assumes there will be some implementation which is provided/filled in by some else (outside). Compare this to frameworks where you have to do lookups to get your depedencies on the other hand.

    -stephan
  34. Some Corrections[ Go to top ]

    Avalon is definitely the oldest IoC container but not really big... It's basically just a set of interfaces for components and service managers, with various implementations in sometimes unclear states.


    Currently there are three containers. One is Phoenix, the beefy big boy with JMX support, configuration validation, etc. The second is Fortress, a lighter weight container with asynchronous component management. Lastly, the sleeper which is gearing up for a release is Merlin which will incorporate all the good points between Phoenix, Fortress, and add some new goodies. The interfaces are a consistent contract with the container.


    > For wiring up, every Avalon component needs to look up cooperating components via the Avalon ServiceManager, passed to automatically if it implements the Serviceable interface. This is very intrusive, as practically every application component with dependencies has to implement that Avalon interface. Furthermore, the lookup mechanism is based on the service interface. If you want to receive as specific instance, you have to use the ServiceSelector with a specific key, another special mechanism.

    There are other ways to perform the same thing to be sure. However if you balance when the thing was written, it was pretty nifty at the time. While you claim it to be "very" intrusive, I find it to be quite natural to use. It is similar to a simplified JNDI--so people are used to the concept.

    As to the ServiceSelector comment, you are claiming that you have to do something when it is clear you have never used the framework. ServiceSelector is available if there are several implementations of a type of component (AKA a service). It is not necessary at all, though.


    >
    > Another major difference between Avalon and Spring is that Avalon defines quite a lot of optional interfaces that a component can implement, like Startable, Stoppable, etc. Spring just offers InitializingBean and DisposableBean at the moment, mainly because there has not been demand for explicit start/stop cycles. Alternatively, one can also specify an "init-method" and/or "destroy-method" in the bean definition, so that a bean does not even have to implement a Spring-specific interface for such resource handling callbacks.

    Key word: *can* implement. THe Component writer is not forced to use them if they don't need the type of container/component interaction the interface represents. In your applications there is no demand for start/stop cycles, but in plenty of other applications there are. No need for force everyone to implement them as their need is not universal. That is the Avalon way.

    >
    > The only stable implementation for embedded use like within a web application is Excalibur, which competes with Spring's bean container. Judging from the website and forum activity, Spring is much more actively developed. And of course, Spring's feature set is far beyond the bean container itself.

    Correction. The container you are talking about is Fortress. Stating relative development activity is not really important. Both containers are being actively developed. If there seems to be less activity on one, then it is probably more mature... But I have no feature comparisons for you at the moment.


    > Finally, an example for the easy reuse of an existing bean. The following bean definition sets up a Jakarta Commons DBCP BasicDataSource in a Spring application context, with an example DAO that receives the dataSource via an expose setDataSource method:
    >
    > <bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    > <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property>
    > <property name="url"><value>jdbc:mysql://localhost:3306/mydb</value></property>
    > <property name="username"><value>root</value></property>
    > </bean>
    >
    > <bean id="exampleDataAccessObject" class="example.ExampleDataAccessObject">
    > <property name="dataSource"><ref bean="myDataSource"/></property>
    > <property name="exampleParam"><value>someValue</value></property>
    > </bean>

    Why not a much nicer configuration standard like this:

    <myDataSource>
      <driverClassName>com.mysql.jdbc.Driver</driverClassName>
      <url>jdbc:mysql://localhost:3306/mydb</url>
      <username>root</username>
    </myDataSource>

    <exampleDataAccessObject>
      <exampleParam>someValue</excampleParam>
    </exampleDataAccessObject>

    It's so much easier for the user of your program...

    > With Avalon, you'd have to subclass BasicDataSource too and make it implement Configurable (for the parameters) and Stoppable (for the close call). Furthermore, the example DAO would have to implement Serviceable to look up the DataSource, and use the ServiceSelector mechanism to choose one by some key if there were more than one.

    Not necessarily. For any one type of "bean" (i.e. interface) you only have to make one component that can load up your existing bean instance and populate its set/get methods with the values passed in. I did this for javax.sql.DataSource objects, and it works pretty well.

    As to the set/get for component references, its a matter of style. Avalon Fortress and Avalon Merlin can support both of those styles--as well as the PicoContainer style. It really isn't that hard to support different ways of doing things. The true measure is what makes you more productive. How about runtime diagnostics? Would it be beneficial to expose some internal state so that you can see how your application is doing on memory, component instances, etc.? Avalon has support for instrumenting your components and connecting with an external client to give you nice looking graphs. It's great for tracking down systemic issues in a server application.

    How about not being locked into one logging implementation? Or dynamic unloading/reloading of components?
  35. Some Corrections[ Go to top ]

    Berin,

    First of all, thanks for the comments. I've just got a superficial view of Avalon, so any corrections of my assumptions are welcome.

    > There are other ways to perform the same thing to be sure. However if you balance when the thing was written, it was pretty nifty at the time. While you claim it to be "very" intrusive, I find it to be quite natural to use. It is similar to a simplified JNDI--so people are used to the concept.

    Of course it was pretty nifty at that time, but there may be better solutions now at least for certain scenarios like embedded usage within business applications. Regarding intrusiveness: I admit that "pretty intrusive" would have been the better wording. JNDI is pretty intrusive too, as you need to know about JNDI if you want to fetch an object from it.

    That's why Spring offers a JndiObjectFactoryBean that can fetch an object and expose it as bean reference. Application objects should not have to care where the object is from, e.g. considering a JDBC DataSource: Be it locally defined or from JNDI, an application object just needs to expose a setDataSource(DataSource) method. The container cares for passing a respective DataSource into that bean property, according to the bean definitions.

    > As to the ServiceSelector comment, you are claiming that you have to do something when it is clear you have never used the framework. ServiceSelector is available if there are several implementations of a type of component (AKA a service). It is not necessary at all, though.

    I have *assumed* that ServiceSelector is necessary, e.g. when there are multiple DataSource instances to chooes from. Please correct me if that is wrong.

    I've never claimed to have used Avalon - as I already said, I just know the documentation. Such basic judgements should be possible after doc study though, else the docs aren't too clear about that... or I haven't studied them hard enough ;-)

    > Key word: *can* implement. THe Component writer is not forced to use them if they don't need the type of container/component interaction the interface represents. In your applications there is no demand for start/stop cycles, but in plenty of other applications there are. No need for force everyone to implement them as their need is not universal. That is the Avalon way.

    I didn't mean to leave any other impression. Of course, a component writer can *choose* to implement those callback interfaces. I just wanted to highlight a difference in focus of the frameworks, as Startable and Stoppable are important for server processes but not so much for business code.

    > Correction. The container you are talking about is Fortress. Stating relative development activity is not really important. Both containers are being actively developed. If there seems to be less activity on one, then it is probably more mature... But I have no feature comparisons for you at the moment.

    Glad to hear that they're actively developed. I really wasn't so sure about that, although I found some current discussions about future direction on the mailing list. It seems that Avalon's design itself hasn't been revised for quite a while, though. I agree that a superficial judgment of website and forum activity isn't really fair, so I apologize for that.

    > Why not a much nicer configuration standard like this:
    >
    > <myDataSource>
    >   <driverClassName>com.mysql.jdbc.Driver</driverClassName>
    >   <url>jdbc:mysql://localhost:3306/mydb</url>
    >   <username>root</username>
    > </myDataSource>
    >
    > <exampleDataAccessObject>
    >   <exampleParam>someValue</excampleParam>
    > </exampleDataAccessObject>

    Well, such an XML format is totally custom and can't be validated by a generic DTD. Spring's generic bean definition is very simple (~60 lines of nicely formatted DTD code), very powerful, and validatable. BTW, there are some niceties like <props>, <list>, and <map> that aren't shown in the example.
     
    > Not necessarily. For any one type of "bean" (i.e. interface) you only have to make one component that can load up your existing bean instance and populate its set/get methods with the values passed in. I did this for javax.sql.DataSource objects, and it works pretty well.

    Kind of a bean wrapper component for populating bean properties, if I understand correctly. How do you make such a component return the underlying bean when looked up? Or does the component have to implement the DataSource interface itself in a wrapper style?

    > How about not being locked into one logging implementation?

    Spring chooses the same solution here as Tomcat, Struts, Hibernate, Kodo JDO, and others: Jakarta Commons Logging :-)

    Personally, I think that Avalon is a great framework for development of server processes. That seems to be its main focus, as illustrated by Phoenix and the existence of many respective callback interfaces. I don't get the impression that it is particularly well suited for lightweight usage within business applications, but that may be a matter of taste.

    Finally, please don't interpret my comments as offensive. Admittedly, I choose to apply quite strict judgments from time to time, but I nevertheless discuss for the sake of the arguments. If I have to stand corrected in some respects, then let it be that way - we are all life-long learners.

    Juergen
  36. More Clarification[ Go to top ]

    Of course it was pretty nifty at that time, but there may be better solutions now at least for certain scenarios like embedded usage within business applications. Regarding intrusiveness: I admit that "pretty intrusive" would have been the better wording. JNDI is pretty intrusive too, as you need to know about JNDI if you want to fetch an object from it.

    >
    > That's why Spring offers a JndiObjectFactoryBean that can fetch an object and expose it as bean reference. Application objects should not have to care where the object is from, e.g. considering a JDBC DataSource: Be it locally defined or from JNDI, an application object just needs to expose a setDataSource(DataSource) method. The container cares for passing a respective DataSource into that bean property, according to the bean definitions.

    Component location transparency is something I'm hoping to add to the Merlin Avalon container. I already have it added to a Avalon/Pico DAO framework I've written (see below).

    > I've never claimed to have used Avalon - as I already said, I just know the documentation. Such basic judgements should be possible after doc study though, else the docs aren't too clear about that... or I haven't studied them hard enough ;-)

    I'll admit that some of the Avalon documentation isn't perfect. We're working on that part too. However, it probably would be a good idea to at least _try_ it out. There's been a lot of work in container and component programming lately (pico, xwork, avalon, spring, hivemind, etc.) and we can all learn from each other.

    > Glad to hear that they're actively developed. I really wasn't so sure about that, although I found some current discussions about future direction on the mailing list. It seems that Avalon's design itself hasn't been revised for quite a while, though. I agree that a superficial judgment of website and forum activity isn't really fair, so I apologize for that.

    One of the advantages of Avalon (IMHO) is the stability of the core framework. Avalon developers are particularly loath to change anything and with good reason. Container implementations don't need to track a constantly moving target. There has been quite a bit of discussion about the next generation of containers and frameworks as well, but the current Avalon 4 framework won't disappear any time soon.

    > Personally, I think that Avalon is a great framework for development of server processes. That seems to be its main focus, as illustrated by Phoenix and the existence of many respective callback interfaces. I don't get the impression that it is particularly well suited for lightweight usage within business applications, but that may be a matter of taste.

    Most of the avalon based apps we have running in production are actually standalone desktop applications. Fortress works very well in this case. We're also using Phoenix and Merlin in server and servlet (web apps). Avalon has traditionally been a server framework (Apache Server Framework), but the latest containers allow for some much more creative uses.

    I've recently released version 0.5 (still beta) of JingDAO, a DAO framework that uses (and works within) both Avalon and PicoContainer. You can work with types I, II, and III IoC patterns and it illustrates how the two frameworks can work together.

    -jaaron
  37. Why not a much nicer configuration standard like this:

    > >
    > > <myDataSource>
    > >   <driverClassName>com.mysql.jdbc.Driver</driverClassName>
    > >   <url>jdbc:mysql://localhost:3306/mydb</url>
    > >   <username>root</username>
    > > </myDataSource>
    > >
    > > <exampleDataAccessObject>
    > >   <exampleParam>someValue</excampleParam>
    > > </exampleDataAccessObject>
    >
    >

    HiveMind started with a fixed, validated DTD that resembled the Spring format. The new format is more free-form. It's actually a best-of-both-worlds situation; the XML is validated, but not against a DTD. Extension points in HiveMind have a <schema> element that identifies the elements (possibly nested) and attributes that may be contributed in an <extension>, as well as Jakarta Digester-like rules for converting those XML contributions into Java objects defined by the application (not by HiveMind) ... complete with validations (line precise error reporting, of course).

    So you get the free-form, generally succinct style and the benefits of validated DTD.
  38. The release doesn't address any of the points that are mentioned in the http://www.springframework.org/docs/lightweight_container.html article.

    However, we will write a response to this comparison before PicoContainer 1.0 final is released, and argue the points we disagree with. (Quite a few ;-)

    Also see PICO-18.

    Aslak
  39. JBoss microkernel[ Go to top ]

    JBoss has had a nice lightweight kernel based on JMX since JBoss 3. Would anybody on the JBoss team package this up and market it please? It is probably a bit more robust and full featured.

    Hans
  40. My understanding was the component consumers in pico are forced to implement a constructor that includes all items that will be supplied by the framework. Is this still true? If so, how is that any different from forcing implementation of an interface, or requiring that an exception be thrown?
  41. Pico works[ Go to top ]

    Well all the Spring-FUD aside from biased people not getting the difference between Pico and Nano or describing ALPHA versions:

    PicoContainer works fine. We've used it in SnipSnap and Radeox and it works. It's small with well crafted code, full unit tests and some highly skilled developers.

    I took a look at HiveMind, Spring and other containers and they were much harder to understand. The transition from our homebrewn component system to Pico took less than a day. And we threw out our own AOP system and use Nanning with Nano. Works fine (now ;-)

    And yes, components need to be configured. But this can be done with Pico (or Nano). But you can start with an simple approach and grow with Pico. No need for complex setups front-up. And as I rarely use constructors because they usually come in your way with inheritance or because you end writing new constructors for every new attribute. So this is nice reuse of constructors otherwise not used by me. I like it.
  42. Spring works too[ Go to top ]

    Stephan,

    > Well all the Spring-FUD aside from biased people not getting the difference between Pico and Nano or describing ALPHA versions

    Should I consider that as personal offence? Please try to be more specific in terms of what you consider FUD. I firmly believe that there are many valid arguments in our article. I interpet such broad attribution of FUD as lack of counterarguments on *your* side.

    Obviously Rod and me are biased as the Spring lead developers, but so are Aslak and Berin as Pico respectively Avalon guys. Anyway, I'm definitely not spreading FUD, and I understand Pico's design quite well.

    Regarding alpha versions: At the time of first publishing of our article, Pico was still in alpha... But the design decisions that we criticize are quite fundamental and still there in the current beta.

    > I took a look at HiveMind, Spring and other containers and they were much harder to understand. The transition from our homebrewn component system to Pico took less than a day. And we threw out our own AOP system and use Nanning with Nano. Works fine (now ;-)

    I can understand that Spring seems harder to understand, especially when you start with the full monty. After all, it offers a full-blown application framework. When you just look at the bean container, it is pretty simple... Arguably not harder to understand than Pico and Nano.

    spring-beans.jar is just 90 KB in 1.0 M1, BTW. I see that our documentation doesn't focus on standalone usage of the bean container yet, though.

    > And yes, components need to be configured. But this can be done with Pico (or Nano). But you can start with an simple approach and grow with Pico. No need for complex setups front-up.

    You are obviously not aware of how simple a Spring bean factory can be set up. How about:

      BeanFactory beanFactory = new XmlBeanFactory("/myfiles/mybeans.xml");
      DataSource ds = (DataSource) beanFactory.getBean("myDataSource");

    This can be called in any context, be it web or EJB or applet, with the XML file being in the file system or in the class path... And the XML bean definition format is pretty simple to understand. You can get up and running very quickly.

    If you don't like Spring's XML bean definition format, then use ListableBeanFactoryImpl with a properties file, or StaticBeanFactory with programmatic registration. Or implement your own BeanFactory, possibly deriving from AbstractBeanFactory.

    So you can start with a simple approach and grow with Spring pretty nicely too. Pico isn't any simpler in that respect, it just seems to be as it doesn't offer any other functionality in its distribution.

    Juergen
  43. :-)[ Go to top ]

    Juergen,

    > Stephan,
    >
    > > Well all the Spring-FUD aside from biased people not getting the difference between Pico and Nano or describing ALPHA versions
    >
    > Should I consider that as personal offence? Please try to be more specific in terms of what you consider FUD. I firmly believe that there are many valid arguments in our article. I interpet such broad attribution of FUD as lack of counterarguments on *your* side.

    I don't know what you consider this. But as you wrote you are biased. And writing wrong things about competitors to get user to use your own product is usually called FUD. I hope some Pico guys would write some comparison to yours, but usually they are developing software not writing PR stuff :-) Comparing XP developed ALPHA version is not very legitimite too. I think I don't need counterarguments, I'm just a happy user. I don't care if people use Spring or Pico.

    > I can understand that Spring seems harder to understand, especially when you start with the full monty. After all, it offers a full-blown application framework. When you just look at the bean container, it is pretty simple... Arguably not harder to understand than Pico and Nano.


    Well. That depends. But perhaps I'm not that clever.

    >
    > spring-beans.jar is just 90 KB in 1.0 M1, BTW. I see that our documentation doesn't focus on standalone usage of the bean container yet, though.
    >

    Yes. And all I needed was a simple container to replace our own.
    I didn't want to imply that Spring does not work. I just wanted to say that Pico works fine, at least for us. I'm sure Spring is a fine container.

    -stephan
  44. :-)[ Go to top ]

    Stephan,

    > I don't know what you consider this. But as you wrote you are biased. And writing wrong things about competitors to get user to use your own product is usually called FUD.

    OK, then: What actually factually *wrong* things have I said about Pico or Avalon? Not things that are subject for *misinterpretation*, but obviously *wrong* things. Of course, like everybody else, I'm not perfect, so a wrong detail statement could have slipped in. But I absolutely reject the imputation of deliberate misleading!

    > I hope some Pico guys would write some comparison to yours, but usually they are developing software not writing PR stuff :-)

    I hope they do too, and I'm looking forward to it! BTW, if you look at the Spring development activity: I'm usually developing a lot of software too, especially since I have a day job besides all of this :-) But PR *is* important, and the Pico guys know that too. One could argue that there are currently more lines of docs then lines of code in Pico... ;-)

    >> Arguably not harder to understand than Pico and Nano.
    >
    > Well. That depends. But perhaps I'm not that clever.

    It's not about cleverness, it's about starting in the right place. And I have already admitted that there isn't much documentation on standalone bean container usage for Spring yet. Rod's original book outlines the idea pretty nicely though, it also gives code examples.

    > I just wanted to say that Pico works fine, at least for us.

    Then all the power to you! After all, working code is what it's all about. I've never intended to imply that Pico doesn't *work*, just that it's IoC type 3 model is somewhat flawed for a significant number of usage scenarios.

    BTW, that "IoC type 3" term is more PR than anything else: It implies some kind of inherent superiority while in reality it is a same-level alternative to the bean-based approach (without enabler interfaces). Oh, maybe we should call Spring's bean-based approach "IoC type 4", as we consider it superior ;-)

    Isn't evolution through competition a great thing? :-) I'm glad that there's so much interest in lightweight containers these days. Still enjoying this discussion, having to ignore your FUD remark for this though.

    Juergen
  45. :-)[ Go to top ]

    OK, then: What actually factually *wrong* things have I said about Pico or Avalon? Not things that are subject for *misinterpretation*, but obviously *wrong* things. Of course, like everybody else, I'm not perfect, so a wrong detail statement could have slipped in. But I absolutely reject the imputation of deliberate misleading!


    "FYI, it has to be noted that Spring offers a full-blown application framework, while PicoContainer is "just" a puristic IoC container. It's Spring's *bean container* that competes with PicoContainer. Spring includes the bean container, an AOP framework,..."

    Well factually wrong is hard, FUD usually does not contain hard facts but implications.
    You write PicoContainer is a pure-IoC container contrary to Spring being a 'Bean' container. You're right. But you also now that most people probably will use Nano which e.g. support Bean Style setters. You implicate with mentioning that Spring does AOP, that Pico does no AOP. Nano though does support AOP via Nanning (or others if you drop in your factory). PicoContainer also wants to gather different components so after some time there will be supporting component (full-blown application framework) too. I currently add Jibernate support e.g.

    "But note that PicoContainer's focus is still on the constructor-based approach. "

    PicoContainer's focus is to support different implementations, where the developers (and I) think that constructor-based is best.

    >
    > > I hope some Pico guys would write some comparison to yours, but usually they are developing software not writing PR stuff :-)
    >
    >
    > Then all the power to you! After all, working code is what it's all about. I've never intended to imply that Pico doesn't *work*, just that it's IoC type 3 model is somewhat flawed for a significant number of usage scenarios.

    The main benefit of constructor based support is that your components always work and you don't have a limbo-state between creation and after initialization with setXXX() is finished. I think this is a very good component practice.

    >
    > BTW, that "IoC type 3" term is more PR than anything else: It implies some kind of inherent superiority while in reality it is a same-level alternative to the bean-based approach (without enabler interfaces). Oh, maybe we should call Spring's bean-based approach "IoC type 4", as we consider it superior ;-)

    As Nano supports bean-based and constructor based, should we call this 4.5? :-)

    >
    > Isn't evolution through competition a great thing? :-) I'm glad that there's so much interest in lightweight containers these days. Still enjoying this discussion, having to ignore your FUD remark for this though.
    >

    Yes. Me too. One year ago there was none and we had to do our stuff on our own or use Avalaon (which was much to heavy weight for us). Yes ignore my FUD remark and go more into telling what Spring does and not what Pico does not (in your perception).

    -stephan
  46. meta data[ Go to top ]

    You write PicoContainer is a pure-IoC container contrary to Spring being a 'Bean' container.


    My intent was to outline that Spring consists of numerous frameworks, of which the bean container competes with Pico. Pico is not "just" an IoC container compared to Spring's bean container but to Spring the full monty. This doesn't diminish Pico's value in any way, it just clarifies that Spring should not be reduced to the core bean container. One could even use Spring as data access library for a Pico-based application, for example.

    > PicoContainer's focus is to support different implementations, where the developers (and I) think that constructor-based is best.

    The current Pico docs solely talk about the "IoC type 3", the constructor-based approach. Pico has an *obvious* focus on this, I do not consider my statement as misleading.

    > The main benefit of constructor based support is that your components always work and you don't have a limbo-state between creation and after initialization with setXXX() is finished. I think this is a very good component practice.

    For the price of no circular dependencies and especially no optional parameters. I consider the latter so important that I can't see how this can be ignored. See my BasicDataSource example - "validationQuery" and others are entirely optional. Same for many custom application services.

    The bean-based approach has that "limbo" state but just internally - client objects never always get correctly initialized services. This is what I meant with Pico's "purist" approach: To sacrifice flexibility for the sake of avoiding a theoretical intermediate state.

    > As Nano supports bean-based and constructor based, should we call this 4.5? :

    As I repeatedly said, my main concern is that there's no notion of a specific component instance with Pico, just one implementation class per dependency type. This applies to both constructor-based and bean-based style. Spring supports this nicely, as you know. Sorry to say a thing that Pico and Nano do not do, but this is a very important issue. The article on the Spring website has been stating this clearly for quite a while.

    So there are 2 main conceptual differences between Pico and Spring: The constructor/bean-style issue, and the relation between dependency type and passed-in component instances. I consider the latter to be the even more important, therefore I'll go into more detail on this one.

    Regarding misleading statements: "No meta XML for dependencies" from the Pico website *is* misleading in that it implies that meta data was just an unnecessary nuisance in other frameworks. In reality, Pico requires meta data too, for specifiying implementation classes per type. And for passing in string/int/etc configuration data, there will have to be meta data too.

    As repeatedly said, Spring isn't tied to its XML bean definition format. But a format of that power is *necessary* for specifying implementation classes, configuration parameters, and which particular instance should be passed into some dependency. Noone is able to get rid of that kind of meta data without sacrificing those particular features.

    Spring's bean container chooses to offer full flexibility with as simple meta data as possible. Pico on the other hand chooses a flexibility-losing tradeoff here, with the misleading image that it is still equally powerful - which it isn't. If Pico decides to support multiple instances per dependency type some day, there will be equal power as with Spring today - and equal kinds of meta data. Pico cannot magically escape that basic conditions.

    Juergen
  47. What am I missing?[ Go to top ]

    OK, I looked at the PicoContainer site. I read "The Spring Framework - A Lightweight Container". But, I still don't get it. It is not clear to me what problem is trying to be solved. Why would I want to use one of these containers? What is a real usage scenario?
  48. What am I missing?[ Go to top ]

    I think all of these projects are trying to find ways to let people build better code.

    Even in Java, with all that Object Oriented goodness, you can still write ugly, monolithic code. You can just hide it better ... "see, three seperate objects!" "Yes, but they're so tied together you can use one without the other two."

    So, you've divided up your app (usually, when we say "application" we're talking about the non-ui business logic, the stuff that often ends up inside an application server ... you know, stateless session EJBs and such ... these microkernels are mostly reactions *against* EJBs, to get the benefits without the complexity) ... so you've divided up your app into these little pieces, how do you reassamble them at runtime into something workable?

    That's what the containers do, they figure out how and when to put everything together.

    The InversionOfControl pattern (IoC) means that your code, for production use, is set up so that something "outside" instantiates the individual bits, configures them, connects them together. This is *great* for testing ... it means your unit tests can accurately mimic what will happen in a production app; same code paths, same interactions, just some of the objects are "mock ups" rather than the real thing.

    Basically, my definition for a good framework is something you can use so that the *easiest* choice isn't a shortcut, but is the *right choice*.

    For instance (I tried not to, but I have to plug HiveMind a little) ... the *right choice* in a service environment is to wait to create services until the exact moment they are first needed.

    I'm not sure what Pico does in terms of just-in-time, but HiveMind can create a proxy object that encapsulates the just-in-time service creation. So, in some systems you might see:

    public void myMethod()
    {
      if (service == null)
        service = doSomeKindOfLookup();

      service.performSomeThing();
    }

    In HiveMind, the service will have been previously assigned, so the code is simpler:

    publci void myMethod()
    {
      service.performSomeThing();
    }

    See, that's simpler (no decision, no need to check if it exists, no need to worry about synchronization) but it's also *right* (the actual service is not created, configured, etc., until just-in-time).

    HiveMind gets away with that by create new Java classes and objects that implement the service interface (it does this at runtime using Javassist). Pico is handicapped in this respect by the fact that it will operate on Java classes. Good for quick and dirty, but means some cool things just aren't possible.

    Each of the different containers has its own emphasis; JBoss JMX, Eclipse Plugins, Avalon, Pico, Spring, HiveMind.
  49. What am I missing?[ Go to top ]

    that should be "can't use one without the other two". Kind of undermines my idea. Hate f*ckin typing into these little text boxes.
  50. Pico Example[ Go to top ]

    For one usage scenario of why to use Pico see http://snipsnap.org/space/PicoContainer+Example
  51. Really pleased[ Go to top ]

    I'm really pleased that Hive, Spring and Avalon leads and enthusiasts have arrived here for a great discussion. Those frameworks are truly great, and we are flattered at the attention we get. Keep up the good work :-)

    We are likely to trim some questions from here and add them to our FAQ for posterity. Not directly of course as it's copyright TSS.com

    - Paul Hammant
    * co initiator of PicoContainer & NanoContainer,
      (awed by since-conception committers and enthusiasts).
    * Three year follower and 2.5 year Committer to Avalon.
  52. Really pleased[ Go to top ]

    This is a great discussion, and please don't take my comments to mean I'm knocking your product. It sounds like it works for a lot of people, though I have my own reasons for not going that way, _yet_. In a month or so I'm going to take a look at my own home-grown thing and see if I can't replace it with something either simpler or more functional (or hopefully both).

    I'm especially pleased that this discussion involved 4 different groups plugging their wares, and it didn't devolve into name calling or patent threats. This is the kind of discussion I look for on this site. Congrats to everyone on great products and a great discussion.
  53. Really pleased[ Go to top ]

    I'm using the Spring container on my 3rd project now, and each usage has gone very well. It's hard to describe succinctly, but in practical terms, it acts as a mostly invisible factory that also can handle all configuration needs. An easy integration is to use it in Struts or Webwork to handle loading Action's instead of just do a Class.forName().

    I've read the Pico docs, and there is something very attractive about the idea of a constructor saying "This is what I need in order for you to build me" and then letting the container handle things from there. But I think the Spring guys raise some valid issues though with the constructor approach, and I'm looking forward to hearing the response from the Pico folks.

    One thing to note about Spring is that if there's something you don't like about the DTD used for the XML configuration files, you're free to develop your own schema and build a BeanFactory implementation to read in that schema. As has been mentioned before, BeanFactory is just an interface, so you can do whatever you want to load up the configuration.

    Rob
  54. Really pleased[ Go to top ]

    It can be a fine line between discussing and hyping; I'm trying to keep on the discussing side (though sometimes you don't realize how something you've written will read until after you hit the Reply button).

    HiveMind addresses the particular problems that are near and dear to me, and includes a number of tradeoffs that make sense to me but don't always fit well with others (i.e., reliance on interfaces, runtime bytecode enhancement, lots of XML parsing and effectively static structure); I'll use it for my work, and will be re-architecting Tapestry to take advantage of it. Everyone should use what works for them. But I can't resist reminding people of the available options ...
  55. I've certainly got hesitations about using Picocontainer: looking at a previous OS project of Aslak Hellesoy, xDoclet, that seems to have come to a standstill after more exciting concepts like aspects and this picocontainer appeared at the horizon. That's his good right ofcourse but that makes projects that are supported by him and other 'thrillseekers' like him less suitable in my view for real-world enterprise use. Too volatile.

    Joost
  56. I've certainly got hesitations about using Picocontainer: looking at a previous OS project of Aslak Hellesoy, xDoclet, that seems to have come to a standstill after more exciting concepts like aspects and this picocontainer appeared at the horizon. That's his good right ofcourse but that makes projects that are supported by him and other 'thrillseekers' like him less suitable in my view for real-world enterprise use. Too volatile.

    >
    > Joost

    Well, As I said before, Pico is quite small and works right now. I don't care (well I do personally) if Aslak goes away.

    -stephan
  57. Joost gimme a break.

    I joined the XDoclet project about a year after its inception. After having worked on it for a year and a half I realised that the core code and design was unmaintainable and started on a rewrite. I've been working on that rewrite (XDoclet2) for nearly a year. Check the CVS logs before you spread FUD about me and the projects I participate in.

    When you're working on a rewrite, it makes little sense to work on the old version (XDoclet 1.2.x which is what people are using), especially since the XDoclet team consists of some 15 (more or less active) committers. This is open source dude. Open source is a collective effort, not a one man show.

    Anyway, people moving in and out of open source projects is an inherent property of any open source project. People moving away from a project (which you incorrectly claim I've done) is not a problem in itself. The problems occur when leaving people aren't replaced by other people.

    If fresh blood can't be found, it is usually because the code has rotted (as XDoclet 1.x), or because the project has become obsolete.

    Where do you think inventive forces come from anyway? Sitting still? Jeez.

    Aslak
  58. Well I can imagine you're not amused.

    But still I've given up on xDoclet for enterprise use. You mention yourself that 1.2 is still water. There isn't any milestone to be found in Sourceforge for xDoclet2. I judge opensource projects amongst other things by their constancy of milestones, betas and releases.

    Ofcourse opensource is opensource: if developers develop mainly by following where there fancy takes them that's fine. Good luck to them. But I might decide not to use a product of that.

    And I'll leave it at that.

    groeten,
    Joost

    p.s.
    some literal quotes and reactions
    "Where do you think inventive forces come from anyway? Sitting still?"
    Research is very fine. But I'll hesitate to use research products in an enterprise environment where other factors are at play then intellectual interest and level of innovation.

    "Check the CVS logs before you spread FUD "
    I'm not spreading anything. I'm mentioning my hesitations and the reasons. I did not expect you to agree. The cries of "FUD, FUD!!" in the OSS world in reaction to people with different opinions sometimes reminds me of the social dynamics phenomenon of 'groupthink'.
  59. Joost,

    PicoContainer is 2 months old, it's a small codebase, it has frequent releases and is entirely TDD. It has decent issue tracking and a very active and responsive developer community of more or less five people.

    What more can you ask for?

    Are you saying that because I am involved with an other project that currently lacks some of these characteristics, people should stay away from PicoContainer?

    Would you be more inclined towards using PicoContainer if I left the project? My point is that even if I left, the remaining developers (who are among the best developers I've ever worked with) would have absolutely no problem keeping it alive.

    My concern is that I find your remarks completely off-topic with this thread (which is about PicoContainer), and I'm having trouble following your reasoning.

    Aslak
  60. <quote>But still I've given up on xDoclet for enterprise use. You mention yourself that 1.2 is still water. There isn't any milestone to be found in Sourceforge for xDoclet2.
    </quote>

    Before your make such an idiotic assumption
    1)Join the mailing list.
    2)Search for Xdoclet on Amazon

    Xdoclet is very much alive and kicking !

    -manish
  61. Joost: I am working constantly on XDoclet. Are you missing the commits I am doing? As recently as Sunday?

    Aslak
  62. I just wanted to say *great* thread, I found it most educational.
    I will try to use a container in bP and in future projects.

    (based on this thread, I selected Nano. Spring, Hive and Avalon looked complicated, and I only found example code how to for Pico, but this will be my first use.... but I do teach a lot (Struts) so maybe some of my corporate clients pick up)

    I never even knew of these "designs".

    THANKS

    .V
  63. Late comment...[ Go to top ]

    I too just want to say thanks for a most educating thread. It has given me more insight to this subject than two days of Googling.

    As a side note to the constructor discussions. I always considered giving the user of a class the possibility of using one of several constructors being an ease-of-use issue. The Java API, in many cases, seem to be designed to offer many ways of doing the same thing as a convenience to the class user.

    In this case, the user of the constructor is the container, and the useability issue is less obvious, decreasing the need for multiple constructors.

    I too has chosen to migrate our project to using some PicoContainer.

    Thanks a lot!

    Greger.