Announcement Announcement Module
Collapse
No announcement yet.
Spring IoC in jboss microkernel Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring IoC in jboss microkernel

    Strange, the jboss microkernel IoC looks very similar to Spring's:
    http://docs.jboss.org/nightly/microk...ml/basics.html

    :?

  • #2
    Isn't that amazing? And yet it must be entirely coincidental, because you can search all the pages about their MicroContainer and not find a single reference to Spring :-)

    Comment


    • #3
      It's high time for copyrights on patterns!
      At least in this case, there should be a copyright on the XML schema for Spring IoC... :idea:

      Comment


      • #4
        Now it is going to be interesting to see how JBoss maintain their FUD campaign against Spring while flagrantly imitating part of its core. But I'm sure they'll manage...

        The real question is: if they sincerely believe in open source, why are they imitating a popular and mature product instead of building on it? Is it NIH, dislike of Apache License, or their commercial and political agenda (which seems to be violently hostile to Spring and Interface21)?

        Surely the time would be ripe for another vendor to consider building a kernel that used the original Spring container rather than an imitation...

        Comment


        • #5
          Yikes! These guys are running the risk of isolating themselves here. One of the things that makes Spring so successful is the high-level of third party support. How many third-parties are going to want to maintain JBoss-only configurations, when they can maintain a Spring configuration that will work across all servers?

          Originally posted by SZ
          It's high time for copyrights on patterns!
          At least in this case, there should be a copyright on the XML schema for Spring IoC...
          I hope you're joking.

          Originally posted by Rod Johnson
          Surely the time would be ripe for another vendor to consider building a kernel that used the original Spring container rather than an imitation...
          Isn't that what Geronimo is doing?

          Comment


          • #6
            But is Spring the first container that uses inversion of control?

            I think Spring is a great product, but Spring also builds on concepts found by other products.

            Comment


            • #7
              It did also added a few additional things over : start and stop lifecycle methods to go along with the create and destroy. Sort of a combination of what Spring and Picocontainer (who have start/stop, but not create/destroy). Plus the ability to pass arguments to the create/destroy methods.

              Anyone care to comment why you need that much flexibility?

              Comment


              • #8
                Originally posted by wpoitras
                Plus the ability to pass arguments to the create/destroy methods.
                This is something Spring misses.

                Anyone care to comment why you need that much flexibility?
                What do you mean?

                And Flexibility in Spring is good. Spring is a framework that is going to be used for a wide variety of applications and there will be a lot of different needs.

                Comment


                • #9
                  Interesting, in another blog there is this:
                  As far as all your other claims of how great your "integration" libraries are, I remain totally unimpressed Yes, the IoC, AOP, WF, is interesting stuff, but the rest? Trivial BS. Otherwise we would have copied you long ago.

                  Posted by Bill Burke (24.61.248.137) on October 04, 2005 at 03:52 PM EDT
                  See http://www.jroller.com/comments/jcar...ed_me#comments

                  So I guess the Microcontent stuff contridicts this quote? Its not BS?

                  Comment


                  • #10
                    Originally posted by Alarmnummer
                    Originally posted by wpoitras
                    Plus the ability to pass arguments to the create/destroy methods.
                    This is something Spring misses.

                    Anyone care to comment why you need that much flexibility?
                    What do you mean?

                    And Flexibility in Spring is good. Spring is a framework that is going to be used for a wide variety of applications and there will be a lot of different needs.
                    I'm wondering why having start/stop PLUS create/destroy and arguments to the create menthod is necessary. I don't think it is. But I use Spring, so I've settled into my comfortable little world without it. So I wanted people's comments on what this added to a container?

                    Comment


                    • #11
                      Originally posted by Rod Johnson
                      Now it is going to be interesting to see how JBoss maintain their FUD campaign against Spring while flagrantly imitating part of its core. But I'm sure they'll manage...

                      The real question is: if they sincerely believe in open source, why are they imitating a popular and mature product instead of building on it? Is it NIH, dislike of Apache License, or their commercial and political agenda (which seems to be violently hostile to Spring and Interface21)?

                      Surely the time would be ripe for another vendor to consider building a kernel that used the original Spring container rather than an imitation...
                      I feel its just different approaches. JBoss likes to have more control over the various components of its system. I don't see anything wrong with that. They have its own JMS, AOP, cache, JMX, container (and now a second one, its POJO container). Tomcat + JBoss components can be migrated to Tomcat + JBoss server. Similar to Tomcat + Spring can be migrated to Tomcat + Spring + JBoss server or Weblogic server + Spring.

                      Sure they COULD have used Spring. Or picocontainer/nanocontainer, HiveMind, etc. . But they didn't. Especially give some sort of hostility the JBoss group has towards Spring/Interface21 (IMHO), this is no surprise.

                      Comment


                      • #12
                        Someone has started a discussion on Javalobby.

                        JBoss Microcontainer IoC vs. Spring IoC
                        http://www.javalobby.com/java/forums/t49723.html

                        Comment


                        • #13
                          Hmm, on closer look it appears that their microkernel stuff will run in other application servers.

                          What I like about their approach is that they have put a big emphasis on managing and wiring stateful components (including domain objects), which has historically been Spring's weak suit. Spring's development team has avoided public discussion of stateful services, almost to the point of hubris.

                          I hope that this microkernel product creates enough competition to induce the Spring team to dialogue with us about stateful services, and how to effectively implement them in a Spring 1.3/AspectJ5 world.

                          Comment


                          • #14
                            At the risk of being flamed There are only so many ways to describe a cat (pun on skin a cat ).

                            It isn't totally unconceivable to me that they came up with their schema complete independently.

                            Just my thoughts....

                            Comment


                            • #15
                              Originally posted by cepage
                              Hmm, on closer look it appears that their microkernel stuff will run in other application servers.

                              What I like about their approach is that they have put a big emphasis on managing and wiring stateful components (including domain objects), which has historically been Spring's weak suit. Spring's development team has avoided public discussion of stateful services, almost to the point of hubris.

                              I hope that this microkernel product creates enough competition to induce the Spring team to dialogue with us about stateful services, and how to effectively implement them in a Spring 1.3/AspectJ5 world.
                              But what are the big problems with building statefull services?

                              At the moment I see a few 'problems'
                              1) Service creation. The service can be created by Spring (just like a stateless service). But you need something to retrieve it from the applicationcontext (because you need a new one everytime).
                              2) Life cycle management. Because the service is not a singleton, it isn`t managed by the Spring-container anymore.

                              But these can be solved I think.

                              So what are the reasons why statefull services are difficult to create?

                              Btw: I have no practical experience with Statefull Session Beans or other statefull services (well.. I do.. but these are different than what normally is called a statefull service).

                              Comment

                              Working...
                              X