Announcement Announcement Module
Collapse
No announcement yet.
Container standard? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Container standard?

    I wonder if there is any value in there being a base layer container contract, API, or model. Somewhat like the Aspect Alliance AOP interfaces. That is, what is the minimum a container must provide or adhere to? Yes, I know the marketecture regarding how lightweight container are non-intrusive and all that, but (having being bitten once with an open source project going closed source), there is more to selecting a container, such as training cost. Real interoperability would reduce risks.

    I've had this thought for a while and was brought to mind again reading a discussion regarding Maven 2, at message http://theserverside.com/news/thread...d=33219#165589,
    Jason Van Zyl mentions why Plexus container was chosen as the embedded container, "...Some things I wanted which weren't available were scriptable components, dynamic component addition/updating, pluggable component lifecycles, discoverable components, pluggable component instantiation strategies, and client definable component personalities i.e. Plexus can run an Avalon component along with a Plexus component along with a Pico component if these component personalities are enabled. Plexus now has all these features. "

    What doesn't have these features? Hive-Mind, as usual will claim to do it all, Spring, if it doesn't have it now, will have, Keel, ..., EJB3, ...,

    Anyway, I'll attempt an answer. There are two options, do nothing since the container technology is in rapid flux and should not be curtailed, or do attempt something, else default or industry standards will determine the direction.



    Fun stuff.

  • #2
    Why do you find that container so important? In my application code no reference to Spring (and the Spring container) is made. So there are no dependencies. If I couldn`t use Spring anymore, I could use something else.

    Comment


    • #3
      Its not of course, until you start using more advanced capabilities of the container.

      For example, property resource resolving, will HiveMind do this the same as Spring? I doubt it. So to be interoperable or agile, one would not use Spring's PropertyPlaceholderConfigurer?

      If one is not going to use the full resources of a container, why use it? Or why not use a very simple one that merely provides a simple bean factory? I guess, if one uses any container so that it is truly unreferenced then that is using a very simple container.

      Comment


      • #4
        Originally posted by jbetancourt
        Its not of course, until you start using more advanced capabilities of the container.
        But more advanced (read Spring specific features) won`t be translated to a generic interface.

        For example, property resource resolving, will HiveMind do this the same as Spring? I doubt it. So to be interoperable or agile, one would not use Spring's PropertyPlaceholderConfigurer?
        This is part of Spring, not of my components. In Spring I glue the Components together and enhance them.

        Until now I haven`t had the need to let my objects know about Spring, unless they are Spring specific objects like some kind of factorybean. But the bean that is created doesn`t know anything about Spring.

        If one is not going to use the full resources of a container, why use it?
        Or why not use a very simple one that merely provides a simple bean factory?
        I do a lot more than only bean creation. I setup whole systems in the beancontainer. Connect them, start them, enhance them, register them to all kinds of things (remoting, scheduling).

        Comment

        Working...
        X