Discussions

News: Blogwatch: A comparison of IoC in Spring and WebWork2

  1. Patrick, on the Art of .war blog, took time to share his thoughts on Inversion of Control, and the implementation differences between WebWork2 and Spring. He makes the comparison by ranking both frameworks in his own categories.

    He concludes: "Ideally, XWork would replace their IoC implementation with Spring's, or at least add xml based configuration for the components."

    Patrick's Blog Comparison

    My personal experiences with Struts BYOM (Bring your own Model) philosophy is that it frequently becomes Build your own Mess. Since there is no support for architecture beyond the (unfortunately concrete) Action classes, invariably a mixture of custom properties files, plugins, extended RequestProcessors or other solutions arise, leading to maintenance headaches later. So the Inversion of Control patterns that WebWork2 and Spring support is very appealing. So today I thought I would do a comparison of the two implementations, based on my experiences with them so far.

    Bottom Line Up Front
    In case you are short on time, here's the conclusions first, explanations will come later. So here are our competitors...

    . WebWork2/XWork (Type 1 IoC) - Enabler interfaces link Components to Actions. Xml file defines the Enabler->Component link
    . Spring (Type 2 IoC) - An Xml file links Javabeans (which can be either Actions or components) based on property names.


    So the winners for my arbitrary categories, by order of importance. Now 1 and 2 I consider highly important, 3-9 are nice but not essential.

    - Configurable Components (Spring) - Each bean can have its properties configured via Xml. Webwork gives zero configurablitly of properties.
    - Multiple Components of Same Type (Spring) - Can have two components of the same class that can differ only by single property value. Webwork would need to add a new component and an new interface for EACH new variation of a component.
    - More Flexible Components Lifecycles (Webwork) - Has Request, Session or Application vs Spring (Singleton i.e. Application and Prototype)
    - More targets for configuration (Spring) - Any bean can be configured and retrieved. All parts of the framework can be targeted for components.
    - Simple Configuration (Webwork) - For a small number of frequently used components, Webwork will require less configuration.
    - AOP/Interceptors - (Undecided) Webwork is simple, but can only affect Actions. Spring is more full blown and can wrap any bean.
    - Data Layer Integration (Spring) Good extension points for JDBC and Hibernate
    - More IDEA refactoring friendly (Webwork)- Refactoring a property name will ripple to the Interface, however Spring's xml config files won't change
    - Single Configuration format (Spring) - All config files use the same xml DTD.

    So who wins? On a pure IoC component model, Spring is far more robust and expressive framework that can act as IoC, a registry or even a generic object factory. XWork is a simple (and fairly effective) solution to IoC. Not being able to configure the components in the Xml, like I can with xwork's actions is big handicap for Webwork. But since XWork's component model is integrated nicely into Webwork 2 (which I'm currently using), I'll probably use it until its limitations cause me to integrate Spring. Ideally (if the world revolved around me, which last I checked, it does not), XWork would replace their IoC implementation with Spring's, or at least add xml based configuration for the components.

    Read the full story, including examples to explain some of the concepts mentioned:
    Dueling IoC (Webwork 2 and Spring)

    Editor's Note

    TheServerside recently published the Introduction to the Spring Framework, and will soon be publishing an article on WebWork2. Both are great frameworks.

    Threaded Messages (39)

  2. Refactoring and spring[ Go to top ]

    Eclipse release 3 Milestone 4, lets you change the classname in files other than java too.

    Agreed, that it is not as intelligent as pure java refactoring, but for just renaming classes or methods it works.
  3. jakarta struts have a ServiceManager too[ Go to top ]

    v.0.1
    ServiceManager is a way to make Struts framework pluggable. Main reason to perform this hack was simple - lets extend Struts framework without needs to extend ActionServlet class.
    With ServiceManager each developer can write new service with some additional functions for Struts framework and plug it into the ServiceManager.

    ServiceManager uses single struts-config.xml file to read configuration information and lets to services add its own rules to the digester to support additional config sections in struts-config.xml. Another words - ServiceManager uses 'live' Digester!
    Such trick allow to store all needed config info for all services in application in one file - struts-config.xml. ger too,
  4. I enjoyed reading your comparison, and appreciate the time you spent to detail your findings.

    > - Simple Configuration (Webwork) - For a small number of frequently used components, Webwork will require less configuration.

    Having taken a look at the XWork configuration, I'm wondering why you think it is easier to configure? I personally don't see the additional simplicity with XWork, but I'd like to understand what you are seeing (maybe there's an easier way with Spring you haven't seen and we can explain/document, or it might be something we can improve).

    Since you specify "a small number of components", I'm also wondering which you consider easier to configure for a "real world" sized app.

    In your analysis you also said
    >>In both case, changes to the PenguinDao are needed, but using Spring,
    >>I can put the details (which are more likely to change) into the xml.
    Hopefully this is considered a benefit rather than a lack of simplicity. I think the key word here is CAN. You don't have to make the change so that it ripples to the xml, you can simply make the code-change. However, as you state, details change more often so putting it in the xml makes it more flexible. Bottom-line, putting these details in the configuration is more of a best-practice than a requirement.

    Trevor
  5. \Trevor Cook\
    However, as you state, details change more often so putting it in the xml makes it more flexible. Bottom-line, putting these details in the configuration is more of a best-practice than a requirement.
    \Trevor Cook\

    Flexibility and accomodating frequent change in the easiest possible manner are not always the best choices. There are times when you want something like that in code so that it is checked more rigorously and earlier in the development cycle using an automated tool (like, say, a compiler :-)

    This is the type of thing that I don't think should be indicated as a "Best practice". Reasonable developers can line up on either side of the issue, and your project requirements can have a large impact on the decision as well.

    Going off on a slight rant for a moment, it bugs me when people label something a "best practice" when what they really mean is "this is a best practice if you have this narrow range of goals [insert goals here]".

        -Mike
  6. <Mike Spille>
    Flexibility and accomodating frequent change in the easiest possible manner are not always the best choices.
    </Mike Spille>
    I agree and was referring to when it is a good choice (but obviously wasn't specific enough).

    <Mike Spille>
    There are times when you want something like that in code so that it is checked more rigorously and earlier in the development cycle using an automated tool (like, say, a compiler :-)
    </Mike Spille>
    Yes, and I do have isolated pieces of configuration in code which can be checked by the compiler. However, using automated tools like ant and junit, I can check things "rigorously" and "early" whether it's in code or in xml (or anywhere else). Static type-checking and compilers are definately a valuable tool but not the only one (and not the most appropriate for certain requirements).

    <Mike Spille>
    Going off on a slight rant for a moment, it bugs me when people label something a "best practice" when what they really mean is "this is a best practice if you have this narrow range of goals [insert goals here]".
    </Mike Spille>
    I agree in concept, but I believe I was referring to a specific goal here (of "add something as simple as an order by price for my findAll() method").

    Trevor
  7. Sidenote: Picocontainer[ Go to top ]

    Prety interesting points in patrick's document, but speaking about IoC frameworks, has anyone tried PicoContainer? It doesn´t require an xml configuration file but the only way to tell component dependencies is using parameters in the constructor of the classes. I wish that someone could share experiences developing with this tools.

    Concretely, how do you build a typical business applications using such a IoC tool.

    I've heard that Pico (and his sibling NanoContainer) are being used in some other programs out there as the component engine behind the scenes but I've been wondering since I read about the existence of these frameworks, is it really worthy (besides the obvious theoretical explanation) to use one of this tools when you are told to build an, for instance, e-commerce application?

    When you choose to use Spring or XWork, do you base all your work in the premise that this tools will take care of the component organization?
    Or if you have existing code that you want to improve (or add features, etc.), you should target your refactoring tasks toward one of this frameworks?

    I wish I could see some real world examples of the use of these IoC frameworks in a real application.
  8. Real-world examples[ Go to top ]

    Unfortunately the real-world applications so far built on Spring are not open source or likely to be. However, we are working on a more extensive and "real-world" example, which should make it clear how to build realistic web applications.

    In general, my experience is that the more complex the application, the more value there is in adopting an IoC container. You can get away with ad hoc configuration through Singletons etc with a small app, but it can get messy in apps with a lot more classes.

    You don't need to base all your work on Spring's style of component organization. It's up to you how fine-grained you want IoC management to be. Simply follow JavaBeans conventions for objects you want Spring to manage. As a rule of thumb: if you would otherwise need to use a singleton or some kind of factory, it's probably a good idea to use Spring to manage that object in a Spring application.

    Regards,
    Rod
  9. Real-world examples[ Go to top ]

    I've had great success in real-world applications using a combination of IoC and "registry"-type providers. I built a custom app registry based on the concepts in your book (which later gave birth to the Spring framework). For my use, my registry is quite simple and just provides a means by which service-style classes can be wired up and accessed in a singleton fashion. The configuration file is quite simple, since it's only supposed to deal with what is necessary to configure the services at runtime (service implementations, factories, parameters, etc.). Any service can maintain its own configuration mechanism, so each service can have its own configuration file. So, for example, my app could have separate config files for authorization, authentication, logging, dropdown value lookup, etc. To some, this might be a needless proliferation of configuration files. As I understand it, in Spring, all of this configuration information could go in the same registry file.

    But my experience has shown that this proliferation of configuration files is quite manageable, and in fact makes things easier. There is less SCC contention, since every file represents configuration for a separate service. More importantly, if I need to update something, or find out where a parameter needs to be tweaked, I know exactly where to go; I don't have to wade through a massive, generically named config registry that duplicates a lot of the problems with the Windows registry once you have an app of real complexity. As a side note, my registry can also deal with services that don't have to have configuration files of their own, as well as deal with services that get their configuration from somewhere else, like a database (the high-level registry file lets you specify configuration providers). I think that this works a little more like HiveMind than Spring.

    Given my setup, I tend to look at the Webwork/xwork IoC as an integration point, which makes it perfect for my use (especially since it's already in the framework I'm using). The component hookup in xwork just points to my services (components) managed by my (simplified) app registry. I could also create a custom component manager in place of the DefaultComponentManager if I wanted to get really clever. Again, I get the advantage that each component maintains its own configuration, and that the source of that configuration is both flexible and can work well in a shared-code environment.
  10. Sidenote: Picocontainer[ Go to top ]

    There exists a page on the picocontainer.org where you can find some of the related projects :
    http://www.picocontainer.org/related-projects.html


    The eXo platform project use pico to provide services to its portal, portlet container and portlets. It is really flexible, here is the idea : we define a set of interfaces (called services API, we actually have DatabaseService, MonitorService, CacheService, OrganizationService, CMSService...). Then we build the dependant implementations (the DatabaseService use JDBC while the OrganizationService use Hibernate) using the pico paradigm, in other words constructors like this :

          public CMSService(DatabaseService dbService) {...}

    The service implementation are then packaged into separate jars and deployed in the servlet container or application server (just because we provide a web platform). A scanner discovers them and register the implementation to the pico container. The container then resolves all the dependancies without an xml line.

    Then you can replace the implementation of the service (real world : replace jar) and that will not change anything in your code. This is really really flexible.

    Finally note that, the eXo platform also provide a portlet framework that can manage all the portlet modes in portlet-controllers.xml (and the associated roles) of a portlet. The ActionHandler object are also pico container components and can therefore use the actual implementation of the service :
            public AddItemToShoppingCartAction(ShoppingCartService sCService)
    If the ShoppingCart service implementation change the portlet code willl not have to be changed. This version is much more powerfull than struts and of course dedicated to portlet management.


    Hope this gives an overview of a real life project that use an IoC container.
  11. Sidenote: Picocontainer[ Go to top ]

    From what I've seen of the eXo platform, it sounds like Pico is a very good fit. I believe that Pico can't handle a use case where multiple implementations of an interface need to be in the container, but it sounds like in eXo that that isn't a concern. I don't find the Spring XML to be a big deal at all, but the XML-less nature of eXo's object wiring is definitely an attractive feature.

    Pico's a very innovative idea and implementation, but two things are preventing me from using it. First, I want to do as much property configuration as possible in the IoC container, and with Spring and it's JavaBean approach, that's very easy to do for any primitive type. I can't figure out via the Pico docs how that's done in Pico, if at all, since everything that goes into the constructor needs to be an Object. The second, and bigger, obstacle is that when I've needed to use a vendor API that contains objects that I want to manage in an IoC conainer, the API is almost always built around the JavaBean approach, and thus it's a very hard (and usually impossible) fit for Pico and a very easy fit for Spring. I believe the vision behind Pico is that more and more libraries will be "Pico-ified", but that of course doesn't help today.

    Pico will still work for a lot of use cases, but I think it's hard to argue that it's as flexible as Spring, and the only cost of Spring is an XML file (which I believe it still needed in Pico if you don't go with the scanning approach, although a Pico XML file would be a lot shorter than a Spring XML file, as it would only need to define implementations and not explicitly state associations).

    Rob
  12. Sidenote: Picocontainer[ Go to top ]

    From what I've seen of the eXo platform, it sounds like Pico is a very good fit. I believe that Pico can't handle a use case where multiple implementations of an interface need to be in the container, but it sounds like in eXo that that isn't a concern. I don't find the Spring XML to be a big deal at all, but the XML-less nature of eXo's object wiring is definitely an attractive feature.


    Pico can handle multible implementations of an interface and it is doing very well indeed. The proof of concern is the eXo platform portlet container : all portlet implementations (javax.portlet.Portlet) are registered in the container. The way this is done is very simple and powerfull (which is the best advantage of pico) :
          picocontainer.registerComponentInstance(portletName, portletClass);

    >Pico's a very innovative idea and implementation, but two things are preventing me from using it.

    Yes, that is right! It is one of the smartest thing I have ever seen in Java and computer science. It is a so simple and powerfull idea (note that simple does not mean easy).

    >I want to do as much property configuration as possible in the IoC container, and with Spring and it's JavaBean approach, that's very easy to do for any primitive type. I can't figure out via the Pico docs how that's done in Pico, if at all, since everything that goes into the constructor needs to be an Object.

    Yes that is true, you need Object in pico container component constructors but those objects are not necessary components they can also be Parameters like ConstantsParameter or ComponentParameter. All the configuration is then treated the same way components are. Once again very simple. The lack of documentation in the pico site is not a problem (it is getting better and will be ready for 1.0 according to the pico team) because the unit test case set is very complete. If you need an information just look at them for now.

    >The second, and bigger, obstacle is that when I've needed to use a vendor API that contains objects that I want to manage in an IoC conainer, the API is almost always built around the JavaBean approach, and thus it's a very hard (and usually impossible) fit for Pico and a very easy fit for Spring. I believe the vision behind Pico is that more and more libraries will be "Pico-ified", but that of course doesn't help today

    This is not impossible at all : just need to write an adapter that will then delegate the work to the API implementation. It is not really a big problem, isn't it :)

    Also pico is only 3 to 4 months old and the components are just getting to be built (have a look at the Nano project or the eXo platform services).


    >Pico will still work for a lot of use cases, but I think it's hard to argue that it's as flexible as Spring, and the only cost of Spring is an XML file (which I believe it still needed in Pico if you don't go with the scanning approach, although a Pico XML file would be a lot shorter than a Spring XML file, as it would only need to define implementations and not explicitly state associations).

    Actually the scanning approch requires an XML file in the eXo platform to define - as you said the implementation to use from the jar (one tag). I have to say that I personnaly think that the pico approch is as flexible (if not more) as the Spring one. Use pico once and you will adopt it :)

    The last point I would like to focus on is the unit test way. With the service design (using pico) we have been able to build a strong unit test case framework. In the TestCase class you just need to register or define MockObejcts in the constructor :
          CMSService service = new CMSService(new MockDatabaseService());
    and then test and assert using the service object. Isn't that nice...and again simple.

    Cheers
  13. Sidenote: Picocontainer[ Go to top ]

    Thanks for the response, Benjamin. My only beef with the adapter approach for handling vendor API's is that these API's often can be used in a variety of ways with optional settings and so forth. I know this conflicts with the Pico team's idea of "good citizens" - that is, vendor API's often allow for objects to be in unusable states - but that's reality. The thing is, I will most likely end up writing an adapter that contains a constructor to handle every possible initialization of the API. You're right, it's doable (I hadn't thought through the adapter approach well enough before), but to me, the tradeoff involves managing some extra XML in the Spring config file vs. writing and testing a layer of adapters. To each his/her own, perhaps.

    I looked at the Pico test cases - they are pretty good. But I didn't see an example of how to use a primitive in the constructor. "BeanPropertyComponentAdapterFactoryTestCase" has an example Foo class that only has a String property. Maybe I'm missing something? Actually, if I have a component that has a method like "setInt(int i)", it seems like the adapter approach would work here, since I can create a constructor in the adapter with an Integer argument and do a "setInt(theInteger.intValue())"... but... I kinda feel like I'm starting to jump through some hoops to do something simple. It seems like the core idea of Pico is simple and elegant, but it then requires some workarounds to handle use cases that I can do very easily in Spring. An adapter, while it is of course a design-patternish word, is in essence a workaround and represents something that has to be designed/built/tested/maintained, no matter how trivial it is.

    To me, the tradeoff between Spring and Pico is - with Spring, you have to follow a JavaBean approach and you have to write/maintain a larger XML file (I say XML, but both Spring and Pico can be configured in any manner); with Pico, you have to follow a constructor approach and you have to write/maintain a much smaller XML file (I'm guessing that eXo's small XML file, consisting of just defined jar files, has to grow somehow in order to handle parameters), but you may find yourself having to write adapters and other interfaces to support the constructor approach (and I'm not sure how primitives are elegantly handled). I know there's also the Pico benefit of guaranteed state, although that's probably a discussion for another thread, as when it was broached in the Pico announcement thread, there were strong responses on both sides of the topic.

    But thanks for the response. It may be worth Wiki'ing answers to questions like these, because the Pico docs could do a better job of addressing use case questions. I think both Spring and Pico are good IoC solutions, but they each have tradeoffs, and obviously understanding them is the key for users to know which one to use for their own situations.

    Rob
  14. Sidenote: Picocontainer[ Go to top ]


    >I want to do as much property configuration as possible in the IoC container, and with Spring and it's JavaBean approach, that's very easy to do for any primitive type. I can't figure out via the Pico docs how that's done in Pico, if at all, since everything that goes into the constructor needs to be an Object.
    Yes that is true, you need Object in pico container component constructors but those objects are not necessary components they can also be Parameters like ConstantsParameter or ComponentParameter.

    Ok, so there's a relatively hard way of doing it in PicoContainer. Why should it be this hard? Why should it not work with any class written without awareness of PicoContainer?


    >The second, and bigger, obstacle is that when I've needed to use a vendor API that contains objects that I want to manage in an IoC conainer, the API is almost always built around the JavaBean approach, and thus it's a very hard (and usually impossible) fit for Pico and a very easy fit for Spring. I believe the vision behind Pico is that more and more libraries will be "Pico-ified", but that of course doesn't help today
    This is not impossible at all : just need to write an adapter that will then delegate the work to the API implementation. It is not really a big problem, isn't it :)

    But why should it be necessary to write an adapter? Again the fact that it's possible doesn't justify the fact that you have to adopt Pico workarounds to do it.


    Also pico is only 3 to 4 months old and the components are just getting to be built (have a look at the Nano project or the eXo platform services).

    I'm sure there will be more "PicoComponents" in future, but it doesn't answer the question as to why there have to be special requirements to make something a "PicoComponent". The JavaBeans model was already there and many classes are already JavaBeans. Maybe PicoContainer will reinvent the world in its image, but I think it's hard to justify the need to.

    Btw, Spring now has an "autowire" feature as described in the article so it's only necessary to specify implementation classes in the XML file and Spring figures out dependencies. This can be combined with checking that all dependencies have been resolved. This means that Spring XML files can be quite short if users choose that feature. (Personally I think there's value in explicitly wiring up associations.)

    I think unit testing Spring beans is at least as easy, because the JavaBeans model handles optional properties more elegantly. Obviously part of the point of any IoC container is easy unit testing.

    Regards,
    Rod
  15. Sidenote: Picocontainer[ Go to top ]

    I'm sure there will be more "PicoComponents" in future, but it doesn't answer the question as to why there have to be special requirements to make something a "PicoComponent".


    It is the same point that I focus on in my Jurgen answer : it is not beacuse there is an actual paradigm that this means it must be used for everything. According to me, resolving depandancy through constructors is much more logical.

    There are requirements to make a class a JavaBean either and they are not justified in term of dependancy resolving while using constructors is a much more natural way.

    Last point, with constructors you will never create an object in an instable state... but here also, it is a question of taste.

    Once again I am just an end user and I just try to explain my choice...

    Cheers
  16. Sidenote: Picocontainer[ Go to top ]

    It is the same point that I focus on in my Jurgen answer :

    > it is not beacuse there is an actual paradigm [JavaBeans -- PdH]
    > that this means it must be used for everything. According to me,
    > resolving depandancy through constructors is much more logical.

    This is arguable. But regardless of whether one agrees with this or not, one of the reasons to use a framework is simply because you have a problem to solve and the framework helps doing this more efficiently. This frequently means glueing together different software components and libraries. In Pico, you'd have to write adapters to make them work. In Spring they are first class citizens.

    When there's a deadline to meet, you don't want to spend your time moulding software to fit a framework -- you want your framework to mould itself according to the stuff you want to do.
  17. Sidenote: Picocontainer[ Go to top ]

    Benjamin,

    Thanks for the hint -- I've just reviewed the current Pico codebase again and found that there's indeed a mechanism for registering a named component and specifying a named component as component parameter now. There's also support for simple parameters there. Note that the Pico team has never bothered to respond to the arguments in our article, so we have to dig into the Pico codebase ourselves all the time to find out any new stuff.

    As far as I see though, a specific Pico component can still just have one parameter of any given type, i.e. you're not able to give a component 2 references to different DataSources or even 2 String parameters! This is very limiting: Spring allows you to have any number of parameters of the same type; you can even fill in a DataSource[] of references, or a List of DataSource references, or a String[] of values into a respective bean property easily.

    Regarding reusing existing components: Of course you can write a constructorified Pico adapter for any component! The point is that you explicitly have to do so while Spring allows you to plug in a JavaBean without any kind of customized wrapping.

    Unit testability is a major goal of Spring in general. A Spring bean can easily be filled with mock references, that's not a particular Pico feature at all and has never been. Your example could look as follows for a JavaBean:

      CMSService service = new CMSService();
      service.setDatabaseService(new MockDatabaseService());

    Note that Pico uses the same amount of meta data as Spring in the meantime, i.e. component names, implementation classes, and an array of parameters. This is not simpler than a Spring bean factory in any way. As I've already said, there are other Spring bean factory implementations than XmlBeanFactory: For example, StaticBeanFactory offers a programmatic registration API very similar to DefaultPicoContainer. XML just happens to be the most popular way.

    In the meantime, Spring has also adopted two Pico-inspired features, namely:

    - dependency checking: assuring that all dependencies (i.e. bean properties) of a bean have been populated, for enforcing a fully configured instance;

    - autowiring: populating dependencies without specifying explicit references in meta data, for the case of one single instance of a given type in the container.

    All things considered, Pico is approaching Spring in terms of component configuration options, except that Spring's way naturally allows to have any number of parameters of a given type. So the main differences as of now are the latter one, and the use of JavaBean properties versus constructor arguments. There is no noteworthy difference in terms of complexity of configuration between the two; a Spring bean factory is still more flexible though, as shown.

    As a side note, I feel that the following statement from the PicoContainer homepage is very misleading: "Components also have no meta-info specification. I.e. no XML.". They *do have* meta info, exactly the same as for a Spring bean if you use instance configuration! Meta info stays meta info, no matter if in XML or programmatic registration code. The above Pico statement is nothing more than misleading marketing.

    I guess that in the end the choice will be a matter of taste, i.e. different component programming styles. When the Pico guys see the need to address the above limitation, they will probably invent some way of allowing for multiple constructor arguments of the same type. So in the end, it will solely be about JavaBean properties versus constructor arguments for component configuration. I strongly favor the former, but at least it's good to have choice.

    A summary of the advantages of the JavaBean approach:

    - Specifying references and values per bean property is a natural way of allowing for multiple parameters of the same type for a single component.

    - Populating specific bean properties just if needed is a natural way of allowing for optional parameters (guessing an appropriate constructor isn't).

    - Circular references can be resolved, in contrast to the constructor-based approach (although circular references are not necessarily recommended).

    - Reusing existing JavaBean components is straightforward and does not involve any kind of custom wrapping.

    Juergen

    P.S.:

    > It (Pico) is one of the smartest thing I have ever seen in Java and computer science.

    Well, the idea of using constructors for specifying dependencies is cute but arguably not superior to the JavaBean approach. As I've said, it's just a different component programming model: It's not at all an inherently superior incarnation of IoC as that "IoC type 3" brand of Pico suggests. Lightweight containers are neither higher inspiration nor magic nor rocket science.

    If you're happy with Pico, I encourage you to use it wherever you like -- this is about working solutions, after all. I just wish that the "no-metadata oh-so-simple" image of Pico, the result of Pico's initial PR, gets replaced by the more realistic view that it is comparable to a Spring bean factory in terms of both amount of metadata and ease of use.
  18. Sidenote: Picocontainer[ Go to top ]

    Jurgen,

    >I guess that in the end the choice will be a matter of taste, i.e. different component programming styles. When the Pico guys see the need to address the above limitation, they will probably invent some way of allowing for multiple constructor arguments of the same type. So in the end, it will solely be about JavaBean properties versus constructor arguments for component configuration. I strongly favor the former, but at least it's good to have choice.


    Ok so you saw for the primitive parameters, but it seems you did not see that pico support multiple constructors for quite a long time now.

    But you are right it is a question of choice and I chose according to my needs, ie the eXo platform. The JavaBean paradigm must not be used for everything and resolving dependancy through constructors is a much natural way of doing so (they are constructors as there name say :)).

    Also note that i am an end user of pico but not a developer of the kernel so I speak in my name - and in the neame of the eXo platform dev team. I think that they wait the first release to answer you.
  19. Sidenote: Picocontainer[ Go to top ]

    Ok so you saw for the primitive parameters, but it seems you did not see that pico support multiple constructors for quite a long time now.


    Oh, I did: That's why I indicated "guessing an appropriate constructor isn't" with respect to a natural way for optional parameters. I know that Pico tries to use the most elaborate constructor than can be resolved with the registered components. The Pico guys still recommend one single constructor, though.

    Providing multiple constructors is not at the same level as allowing for any kind of optional parameters though: With JavaBean properties, you don't need to offer overloaded central initializers. Example: For 3 String properties A/B/C, you can choose any mix of config values (2^3=8: none, A, B, C, A/B, A/C, B/C, A/B/C) without the need for any additional code beyond the 3 bean property setter methods. To achieve the same with Pico, you would need 8 overloaded constructors, provided that Pico could work with multiple String arguments for one single component at all (which it currently doesn't). Now think of how many (optional) properties for example the Jakarta Commons DBCP BasicDataSource has.

    Of course, component dependencies often need to be resolved completely or just in a few possible combinations. But primitive/String component parameters are significantly different: There are many scenarios where a lot of optional parameters make sense. Pico's constructor-based approach will never be able to deal with such scenarios in a satisfying fashion (i.e. without a large number of overloaded constructors). Again, provided that it could work with multiple parameters of the same type for a single component at all.

    Essentially, the Pico approach suits component dependencies (if you like the constructor approach for this), but is arguably unhandy or even unusable for parameter dependencies, particularly multiple and optional ones.

    > Last point, with constructors you will never create an object in an instable state... but here also, it is a question of taste.

    True, even when the objects are used without Pico; but are these tradeoffs (multiple params, optional params, reusability of existing beans) really worth it? And with Spring's new dependency checking (configurable to check just component dependencies, just primitive params, or both), you won't create objects in an instable state either - while keeping all the benefits of the JavaBean approach.

    Of course, Pico may be a good choice for eXo; I don't want to discredit your choice at all. I still argue that the Spring bean factory approach is more flexible and more powerful than Pico's constructor approach, at a simple expense: References and parameter values for Spring beans are specified per bean property name, while dependencies for Pico components are specified per dependency type - losing the ability to have multiple dependencies of the same type. If the latter gets relaxed to specify dependencies per constructor argument name, Spring and Pico will use exactly the same amount of metadata.

    Bottom line, provided that Pico adopts the latter suggestion (which it probably won't immediately if at all): Two different component programming styles, similar power of configuration, comparable amounts of meta data (in Java registration code or XML definitions). Pico style advantage: Guaranteeing fully configured objects even without a container. Spring style advantages: Allowing for optional parameters and reuse of existing beans in a natural way (plus support for multiple parameters of the same type, for the time being). Now consider your requirements and choose wisely.

    Juergen
  20. Sidenote: Picocontainer[ Go to top ]

    [quote]
    From what I've seen of the eXo platform, it sounds like Pico is a very good fit. I believe that Pico can't handle a use case where multiple implementations of an interface need to be in the container, but it sounds like in eXo that that isn't a concern. I don't find the Spring XML to be a big deal at all, but the XML-less nature of eXo's object wiring is definitely an attractive feature.
    [/quote]

    We solve this problem by define explicitly an interface for each service. Take the CmsService as example we can have a file base system implementation and database system implemntation so we define

    interface FileCmsService extends CmsService {

    }

    interface DatabaseCmsService extends CmsService {

    }

    and create an wrapper service

    class CmsWrapperService {
      CmsWrapperService(FileCmsService fservice, DatabaseCmsService cservice) {
      
      }
    }

    and in action class

    class PortletAction (CmsWrapperService wrapper) {
      CmsService service = wrapper.getCmsService("FileCmsService") ;
    }

    Or you can register the service with picocontianer by name, so you will have multiple implementation
  21. Sidenote: Picocontainer[ Go to top ]

    Prety interesting points in patrick's document, but speaking about IoC frameworks, has anyone tried PicoContainer? It doesn´t require an xml configuration file but the only way to tell component dependencies is using parameters in the constructor of the classes.


    You might be interested in the article at http://www.springframework.org/docs/lightweight_container.html -- in the final section, it discusses Spring bean factory vs Pico in terms of conceptural differences.

    There are three main conceptual differences:

    - A Spring bean factory uses bean properties instead of constructor arguments, supporting optional properties or strict dependency checks (this is configurable). Pico classes have a fixed set of dependencies.

    - A Spring bean factory configures named bean instances, allowing for multiple instances per type, like multiple JDBC DataSources etc. Pico's concept only supports one instance per type at runtime.

    - A Spring bean factory supports IoC-populating simple parameters (primitives, Strings) with the same mechanism, while Pico just targets component dependencies. With simple parameters, you need multiple instances per type.

    Spring's JavaBean-based concept allows for easy reuse of existing beans, like for example a Jakarta Commons DBCP BasicDataSource. Configuration via bean properties is pretty common in the Java universe, particularly for a large number of parameters where most of them are optional.

    So eventually, Spring uses the minimal amount of metadata necessary for the targeted level of configuration power. Pico sacrifices named instances for a simpler one-instance-per-type model. Pico *does* need metadata though: At least, it needs the name of the concrete class to use for each component type.

    Note that there are multiple Spring bean factory implementations, offering different configuration styles: XML definitions, properties files, and programmatic registration are supported out-of-the-box.

    Juergen
  22. Sidenote: Picocontainer[ Go to top ]

    Jurgen most of the remarks done in this article are out of date :).

    Once again pico is a new project (3 to 4 months old) and was really improved the last two months.

    Just have a look at my last post for some points and comments.

    Cheers
  23. Sidenote: Picocontainer[ Go to top ]

    <Juergen>
    So eventually, Spring uses the minimal amount of metadata necessary for the targeted level of configuration power. Pico sacrifices named instances for a simpler one-instance-per-type model. Pico *does* need metadata though: At least, it needs the name of the concrete class to use for each component type.
    </Juergen>

    I think it's a mood point, if you need metadata or not. But it's hard to call constructor
    parameters metadata. Then all method parameters would become metadata and one could argue all interface descriptions are metadata. I don't think this is a good usage of the term metadata.

    bye
    -stephan
  24. Sidenote: Picocontainer[ Go to top ]

    Hi Stephan,

    > I think it's a mood point, if you need metadata or not. But it's hard to call constructor
    > parameters metadata. Then all method parameters would become metadata and one could argue all interface descriptions are metadata. I don't think this is a good usage of the term metadata.

    To clarify my use of the term metadata: I don't call constructor arguments metadata. I *do* call programmatic registration of components metadata though; whether registration happens via XML definitions or Java code does not make a difference. Both are "metadata" in the sense that they describe component configuration and dependencies. My point is that Pico does not inherently need less metadata than Pico; that has been claimed but not proven yet. After all, you need the kind of component descriptions that I have outlined; look at Pico's registration API. Neither Spring nor Pico can do magic in that respect.

    Eventually, it will turn out that the main difference between Spring and Pico is the use of bean properties versus constructor arguments. Additionally, Spring recommends the use of XML definitions while Pico's default is programmatic registration. Of course, both offer alternative means of defining components too: Spring allows for programmatic registration just like Nano implementations allow for XML definitions. As Rod has indicated, competition is a good thing: So all the best for Pico's future; I just wish that the Pico team stopped making their misleading "no metadata" claims.

    Juergen
  25. Sidenote: Picocontainer[ Go to top ]

    Juergen,

    if you call method calls metadata, then I understood your posting wrong. It's arguable if calling methods to add objects to containers metadata, but at least I can see the point in the argument.
    On the other side, I can also follow the no-metadata argument. I really do not think calling methods to add objects to an container can be called metadata. Calling Pico no-configuration or configuration-free would be wrong though from my point of view.

    But as a whole, summing up all this discussions and reading some Spring documents (the TSS tutorial was nice), I think the differences between Spring and Pico are very small. Both do programatic or XML configuration, Pico does bean style components and so on.

    I just wish the Spring team would stop exaggerating differences and concentrate on JDBC, JTA and Hibernate features to promote Spring ;-)

    bye
    -stephan
  26. Sidenote: Picocontainer[ Go to top ]

    Juergen,

    On the other side, Pico documentation (which is really not good enough guys) confuses me and I may be all wrong, which I probably am :-) Spring documentation is much better (although I can't find Hibernate integration tutorials beside the JTA tutorial, and I don't care about transactions. Where do I have to look for easy Hibernate and Spring integrations tutorials?) Why does Spring not support C-Type IoC?

    And you do a faboulus job on recruiting new Spring users ;-)

    bye
    -stephan
  27. Sidenote: Picocontainer[ Go to top ]

    (although I can't find Hibernate integration tutorials beside the JTA tutorial, and I don't care about transactions. Where do I have to look for easy Hibernate and Spring integrations tutorials?)


    Have you read the article at http://www.hibernate.org/110.html -- also linked from the documentation section on our website? It outlines all the configuration options. And as I've announced, 1.0 M2 will contain a working Spring/Hibernate app in the form of the reworked Petclinic sample. 1.0 M2 will be released this week, BTW.

    Juergen
  28. Sidenote: Picocontainer[ Go to top ]

    Stephan,

    You've got a point regarding "metadata-free" versus "configuration-free". Then a Spring bean factory can be metadata-free too of course, when using programmatic registration. This is not a particular Pico benefit.

    > I just wish the Spring team would stop exaggerating differences and concentrate on JDBC, JTA and Hibernate features to promote Spring ;-)

    I've actually tried to show how similar Pico and Spring are! I think I've clearly outlined both the similarities and the noteworthy differences that remain. I've never seen an attempt to such an analysis from the Pico people BTW.

    Regarding concentrating on Hibernate and co: Oh, we do! :-) The generic transaction management, particularly declarative demarcation, and the Hibernate support are very popular among users. There's a lot going on in that areas:

    - The upcoming release 1.0 M2 will contain a reworked Petclinic sample app that can be configured for either JDBC or Hibernate as data access strategy.

    - We are working on source-level metadata support for the M3 milestone, with the main use case of transaction demarcation via source-level attributes.

    - Generally, we aim to make AOP as convenient as possible, for example allowing to auto-proxy beans in a bean factory.

    - The web framework provides pluggable multipart handling now, support for Tiles as view technology, etc.

    - We already have seamless remoting support via transparent RMI/Hessian/Burlap; we are planning to offer SOAP support via Glue and Axis.

    You might wonder why there's still time for discussing basic bean container design decisions -- I do too! ;-)

    Juergen
  29. Pico usage[ Go to top ]

    <quote>
    I've heard that Pico (and his sibling NanoContainer) are being used in some other programs out there as the component engine behind the scenes but I've been wondering since I read about the existence of these frameworks, is it really worthy (besides the obvious theoretical explanation) to
    use one of this tools when you are told to build an, for instance, e-commerce application?
    </quote>

    We use SnipSnap with Pico, it's opensource and Pico is worth to use. Indeed, I would not build an application in the future without Pico (or Spring should the requirements demand Spring features).

    bye
    -stephan
  30. Pico usage[ Go to top ]

    We use SnipSnap with Pico, it's opensource and Pico is worth to use. Indeed, I would not build an application in the future without Pico (or Spring should the requirements demand Spring features).

    I'll second that. I guess it's natural that there's competition between IoC implementations. But I firmly believe that using any IoC container is a huge advance on doing without such a consistent infrastructure.

    Regards,
    Rod
  31. Spring + XDoclet[ Go to top ]

    I have been evaluating Spring for the last week and I like what I see so far. However, after I have gone back and forth between by implenetation code and the XML configuration used to "wire" my code together, I keep thinking...wouldn't XDoclet (or soemthing like it) help here?

    Has anybody else suggested this? Is this a bad idea? Is a Spring XDoclet plugin already in the works?

    Ryan
  32. Spring + XDoclet[ Go to top ]

    Ryan,

    What kind of configuration would you keep in javadoc tags? Bean property values? Bean references? If you did that, you could as well hard code defaults into your implementation class and just configure the class name in the Spring application context:

      <bean id="myBean" class="myPackage.MyBeanClass"/>

    Even if the bean offers property setters, you don't need to address them -- the bean will simply use its default values then. As for bean references, you could use the new "autowire" feature that is introduced with the upcoming 1.0 M2:

      <bean id="myBean" class="myPackage.MyBeanClass" autowire="byType"/>

    That would automatically populate your non-primitive bean properties with respective beans from the application context. For example, if your bean has a property of type DataSource, the bean factory will fill it with a reference to the DataSource bean in the application context. If there was more than one or no bean of type DataSource, an exception would get thrown.

    I consider the above metadata so simple that I can't imagine how XDoclet could help here. I believe that Spring's mechanisms allow you to keep source-related stuff in source code anyway. If you want, the XML file can just consist of the bare minimum that a factory requires: bean names and implementation classes.

    Juergen
  33. Spring + XDoclet[ Go to top ]

    Well, even *if* all I had in the configuration file was the bean name and the implementation, I wouldn't mind having this generated. That is just one less thing I have to touch when I create/rename/repackage a class. But hey, I am quite lazy :-)

    I can see it coming in handy in several other places as well. For example, say I have a SimpleFormController. This XML:

      <bean id="createStoreController" class="web.CreateStoreController">
        <property name="beanName"><value>store</value></property>
        <property name="commandClass"><value>store.Store</value></property>
        <property name="formView"><value>createStoreForm</value></property>
        <property name="successView"><value>createStoreSuccess</value></property>
        <property name="storeServices"><ref bean="storeServices"/></property>
      </bean>

    with this:

    /**
     * @spring.class
     *
     * @spring.property
     * name="beanName"
     * value="store"
     *
     * OTHER PROPERIES HERE
     */
    public class CreateStoreController extends SimpleFormController {
       ...
    }

    It's about the same in verbosity, but it is all contained in one file. Another thing I can think of is methods that require transaction interception can be marked as so. However, other things, such as view mapping, I really can't see being placed in a Java file. Plus, I can see how autowiring would help a lot down the road - currently all of my dependencies are unambiguous. and could be handled this way.

    Maybe this idea is yucky. I don't know. I do know I have been hopping back and forth between my Java and XML config files quite a bit.

    Great work.

    Ryan
  34. Spring + XDoclet[ Go to top ]

    Ryan,

    > Well, even *if* all I had in the configuration file was the bean name and the implementation, I wouldn't mind having this generated. That is just one less thing I have to touch when I create/rename/repackage a class. But hey, I am quite lazy :-)

    IntelliJ IDEA automatically refactors class names in XML files -- I happen to be quite lazy too :-)

    >   <bean id="createStoreController" class="web.CreateStoreController">
    >     <property name="beanName"><value>store</value></property>
    >     <property name="commandClass"><value>store.Store</value></property>
    >     <property name="formView"><value>createStoreForm</value></property>
    >     <property name="successView"><value>createStoreSuccess</value></property>
    >     <property name="storeServices"><ref bean="storeServices"/></property>
    >   </bean>

    What about initializing the default of these properties in the constructor of your subclass? I usually do this; if you don't need configurability outside of the source code, this can cut down your controller definitions to just the id and the implementation class.

      public class CreateStoreController extends SimpleFormController {
        public CreateStoreController() {
          setBeanName("store");
          setCommandClass(Store.class);
          ...
        }
      }
     
    > Another thing I can think of is methods that require transaction interception can be marked as so.

    We are actually working on support for source-level metadata, with transaction demarcation being the main use case. This will not work via XML generation though, but rather via:
    - a build step that injects the attributes into the class file;
    - runtime inspection of the class file to determine them;
    - and automatic proxy generation in case of transaction requirements!
    Stay tuned, this is targeted for 1.0 M3 in mid November.

    Juergen
  35. Spring + XDoclet[ Go to top ]

      public class CreateStoreController extends SimpleFormController {

    >     public CreateStoreController() {
    >       setBeanName("store");
    >       setCommandClass(Store.class);
    >       ...
    >     }
    >   }

    I realized this about a minute after I wrote that. Like I said, still learning the framework.

    > > Another thing I can think of is methods that require transaction interception can be marked as so.
    >
    > We are actually working on support for source-level metadata, with transaction demarcation being the main use case. This will not work via XML generation though, but rather via:
    > - a build step that injects the attributes into the class file;
    > - runtime inspection of the class file to determine them;
    > - and automatic proxy generation in case of transaction requirements!
    > Stay tuned, this is targeted for 1.0 M3 in mid November.
    >
    > Juergen

    Sounds exciting. Looking forward to the next release.

    Ryan
  36. Rod
    Any thing in the pipeline to provide development support for Spring framework on Eclipse?

    thnanks
  37. Any thing in the pipeline to provide development support for Spring framework on Eclipse?
    Yes, we plan to look at tool support as a major priority after Spring 1.0 final.
  38. IOC, SQL, WEB...hmmm[ Go to top ]

    Rod,

    You have said two things I'd like to focus on:

    'In general, my experience is that the more complex the application, the more value there is in adopting an IoC container. You can get away with ad hoc configuration through Singletons etc with a small app, but it can get messy in apps with a lot more classes. '

    'I'll second that. I guess it's natural that there's competition between IoC implementations. But I firmly believe that using any IoC container is a huge advance on doing without such a consistent infrastructure. '

    My equivalent comment is:

    'In general the more complex an application, the more important is a design authority and good team communication.'

    Use of a framework, buzz word, high level language etc is irrelevant. BUT, I am going to use Spring or Pico, because it's kinda wierd to think that a framework provides a better solution than an architecture tailored for the project, and, maybe, you have something. Or maybe its just another flash in the pan.

    I quite like the SQL stuff in spring as well. And please do NOT climb onto hibernate as an important cornerstone. Too many things require buying into a world view (aka Avakalon).

    Jonathan
  39. IOC, SQL, WEB...hmmm[ Go to top ]

    Jonathan,

    > 'In general the more complex an application, the more important is a design authority and good team communication.'

    Good point. The question is, what approach is the design authority going to adopt? A good design authority should neither fall for the Not Invented Here nor the Only Established Industry Standards Are Acceptable syndrome.

    > Use of a framework, buzz word, high level language etc is irrelevant. BUT, I am going to use Spring or Pico, because it's kinda wierd to think that a framework provides a better solution than an architecture tailored for the project (...)

    Of course no specific product can be the cornerstone of appropriate architecture. But I guess you agree that it is preferable to adopt a well-designed and well-tested existing infrastructure instead of rolling your own, particularly if the requirements match to a high degree.

    A framework that is as non-intrusive as possible and does not require buying into a different world view is naturally easier to adopt. Many existing so-called "application frameworks" tie you into their solution for everything; Spring on the other hand aims to offer a different approach in that it allows for true best of breed choice despite having adopted an "application framework".

    > I quite like the SQL stuff in spring as well. And please do NOT climb onto hibernate as an important cornerstone. Too many things require buying into a world view (aka Avakalon).

    Hibernate is and will be a first class persistence solution within Spring, as it is straightforward to integrate and a really nice O/R mapping tool :-) We will by no means solely concentrate on Hibernate, though: We currently offer dedicated support for JDBC, Hibernate, and JDO -- in terms of transaction strategies and DAO support classes.

    BTW, the upcoming release 1.0 M2 has a reworked Petclinic sample app, with alternative DAO implementations and application context configurations for JDBC and Hibernate, on HSQL and MySQL. This illustrates our approach nicely: integrate instead of reinvent, but always with an appropriate level of abstraction.

    Juergen
  40. IOC, SQL, WEB...hmmm[ Go to top ]

    Jonathan,

    In general the more complex an application, the more important is a design authority and good team communication.
    I agree. No framework--Spring, Pico, Struts, Keel or anything else--can replace the contribution of people who know what they're doing and have a clear design vision. Nor should a framework attempt to. I see good frameworks as tools that make it easier to implement a good design, appropriate for that application. I don't think frameworks should be overly prescriptive. We try to avoid that route with Spring. Unlike some frameworks (you mentioned Avalon) we don't aim to force you into our world view.

    Regards,
    Rod