Geronimo Gbean Architecture

Discussions

News: Geronimo Gbean Architecture

  1. Geronimo Gbean Architecture (16 messages)

    Geronimo is built on a J2EE agnostic Kernel and is positioned as a general-purpose Inversion of Control (IoC) framework for components called GBeans. This article explains the theoretical aspects of the IoC framework, describes the GBean Life Cycle, GBean States and Dependency Injection with a few examples, and concludes with an explanation of how to write a simple GBean.

    GBeans bear a lot of resemblance to JMX beans, and the architecture seems very similar to JBoss at first glance. What do you think is the differentiation between JBoss and Geronimo, in this context? It's been said by some that Geronimo is more of a generic application architecture with J2EE grafted on it. Does this mean JBoss is not? What do you think of the basic architectural style?

    Threaded Messages (16)

  2. Geronimo Gbean Architecture[ Go to top ]

    Both JBoss and Geronimo are going after the same JavaBean-centric architecture. JMX is great but it is unweildy when used as the basis for anything. JBoss 5.0 will get away from JMX underneath everything.
  3. Geronimo Gbean Architecture[ Go to top ]

    How? JMX is a core technology in J2EE now, and is growing in importance for J2SE.
  4. JBoss 5 Microkernel[ Go to top ]

    How? JMX is a core technology in J2EE now, and is growing in importance for J2SE.

    Joe,

    There is a ton of JBoss 5 Microkernel info on our web site - http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernel is a great place to start.

    As you will see, there are still all the JMX related features that users love about JBoss, but it is a much more complete microkernel...

    Bob Bickel
    JBoss
  5. JBoss 5 Microkernel[ Go to top ]

    Bob, sure... but how does that lessen the importance of JMX for future implementations?
  6. JBoss 5 Microkernel[ Go to top ]

    blockquote>Bob, sure... but how does that lessen the importance of JMX for future implementations?
    Joe, the new kernel doesn't lessen the importance of JMX it just turns JMX into an aspect that can be applied to any component if desired. The new kernel gives us additional flexibility for some new features we want to have as well as turns service development into POJO development. This work is based on the rearchitecting that our Chief Scientist, Adrian Brock is doing. I've blogged more about JBoss 5 Microkernel here.
  7. Geronimo Gbean Architecture[ Go to top ]

    We've got to give it to the Geronimo team for going this way. Sure, you may not like interfaces but interfaces are not always evil. It works for them and they are putting in the pieces they find are essential to a robust app server. doFail() is a great idea. It's not useful for everyone, but in an enterprise app server it is genius.

    I'm glad that JBoss is going a similar route. JMX isn't irrelevant, it just is a side aspect. It's just no fun to do *everything* through an MBeanServer. There are certain essential points which need to be managable, but not everything needs JMX.

    Obviously, much thanks is owed to the guys who pushed IoC before it become obvious to the Java world.
    Steve
  8. What's wrong with JMX?[ Go to top ]

    What's wrong with JMX?

    I thought the whole purpose of the API was to provide an easy out of the box management interface into your components. It is up to you if you tie up every single object into the JMX API or you just do a Management set of components that allows access through JMX and controls your app in general.

    Misuse and deficient design practices should not be blamed on the tools and technologies used.
  9. Geronimo Gbean Architecture[ Go to top ]

    Guys, this is embarassing. By defining your own component model, the GBean, you had the opportunity to relieve users of the most invasive, burdensome aspects of working with the JMX component model.

    Instead, you have come up with something that is just as burdensome, AND it ties us into the Geronimo API's.

    Spring 1.2 has already shown how to deploy POJOs as fully-compliant JMX components. They've done the hard work. Now take your $100 million from IBM and get cracking!

    public class MyGBean implements GBeanLifecycle

    Implementing this interface should be optional. If someone wants to programatically control the deployment, great. But if deployment is going to be done through the container and the config files, the interface can be mixed in at runtime.

    static {
            GBeanInfoBuilder infoFactory = new GBeanInfoBuilder("ConstructorInjectionGbean",
                    GSInjectionGbean.class);

            // attributes
            infoFactory.addAttribute("objectName", String.class, false);
            infoFactory.addReference("Bean1",GBean1.class);
            infoFactory.addReference("Bean2",GBean2.class);
            
            infoFactory.addOperation("getBean1");

            // operations
            infoFactory.setConstructor(new String[]{"objectName"});
            GBEAN_INFO = infoFactory.getBeanInfo();
        }


    For the love of God, no! A static initializer? All this crap belongs in the config file, not in my component. Inject a BeanInfo attribute if you must.

    public static GBeanInfo getGBeanInfo() {
            return GBEAN_INFO;
        }


    Please tell me this is just for fun, and the static method is not required.


        public void doFail() {
            log.info("Axis GBean has failed");
        }


    In the config file, you should optionally specify an implementation of GBeanLifecycle that handles this kind of mind-numbing logging stuff. The user can OPTIONALLY override the implementation if they need something more sophisticated.

    Note that, you should have Apache Maven installed on your machine, to run the test case.

    OK, now you're just trying to piss us off. Back to the drawing board, guys!
  10. Geronimo GBean Architecture[ Go to top ]

    Corby you are such a JBoss shill. I know you guys are scared to have competition but relax man; you're going to give yourself an ulcer.

    I am quite aware of the issues you bring up out, and even pointed them out myself in the presentation I gave at the The Server Side Symposium. I have already began addressing these issues, and hope to have GBeanInfo and GBeanLifecycle requirements eliminated soon.

    For the future, I have an experimental replacement of the kernel working that uses Spring to wire together our components. This means you get the full power of Spring with the addition of component lifecycle management, class loader management, and automatic exporting of components to JMX for management. And yes all of that works without adding and GBean specific imports to your classes.

    -dain
  11. Geronimo GBean Architecture[ Go to top ]

    Corby you are such a JBoss shill. I know you guys are scared to have competition but relax man;

    You've got the wrong man, buddy. I've been migrating to Spring 1.2 precisely so I can divorce myself from these types of intrusive API's in JBoss. At least that is a two-year-old design, I was just shocked at an introductory article that suggested you guys were making the same mistakes.

    I have no idea what the JBoss 5 design looks like, but I guarantee that if they do the same silly things described in this article, they will get their asses handed to them as well.
    I have an experimental replacement of the kernel working that uses Spring to wire together our components... And yes all of that works without adding and GBean specific imports to your classes.

    Awesome, you need to get the word out. The article by Mr. Perera makes you look bad.
  12. Geronimo GBean Architecture[ Go to top ]

    Corby you are such a JBoss shill. I know you guys are scared to have competition but relax man;

    You've got the wrong man, buddy. I've been migrating to Spring 1.2 precisely so I can divorce myself from these types of intrusive API's in JBoss. At least that is a two-year-old design, I was just shocked at an introductory article that suggested you guys were making the same mistakes.I have no idea what the JBoss 5 design looks like, but I guarantee that if they do the same silly things described in this article, they will get their asses handed to them as well.

    My bad. I always assumed you were a JBoss employee, and coming from me that is a pretty terrible thing to think of a person. I'm sorry.
    I have an experimental replacement of the kernel working that uses Spring to wire together our components... And yes all of that works without adding and GBean specific imports to your classes.
    Awesome, you need to get the word out. The article by Mr. Perera makes you look bad.

    I'm working on it. The project is focused on J2EE certification, and I have been hacking the Spring based kernel on the side (while the tests are running). The kernel is basically done, but I need to finish packing it up into a bundle that people can test drive. Expect something very soon.
  13. Interesting. As I understand it, that would be wiring Spring at the bottom layer(core) of the J2EE app server, which is completely opposite to what Spring was first designed for: to be a top "simplification" layer above J2EE app servers. Really shows how far Spring has come since its early days.

    Regards,
    Henrique Steckelberg
  14. Spring at its core has always been about this sophisticated object factory that manages the internal architecture of your application. Before Spring, there simply weren't many good solutions for or even much acknowledgement of the whole problem of system assembly and configuration. As a result we saw much abuse of these "server" component models EJB and JMX, where every single object in a system was exported to the application server or MBeanServer, respectively. Thank goodness those days are over...

    It's good to see Geronimo building on Spring to make a lightweight container within a J2EE server a first class thing. My hope is that brings developers the best of both worlds: a facility for managing and configuring the internal components of their applications, combined with the ability to take advantage of the power of the app server where appropriate, to support hot redeployment of applications partitioned accross multiple classloaders, for example.

    Keith
  15. Good point Henrique.
    Geronimo guys must take a look at the Pico/Nano IoC container to really appreciate what 'non-obtrusiveness' means! You don't depend upon the container apis as much as perhaps Spring or other IoC containers out there.
    http://nanocontainer.codehaus.org/

    - Vijay Phadke
  16. Consider Pico/Nano Container[ Go to top ]

    Good point Henrique.Geronimo guys must take a look at the Pico/Nano IoC container to really appreciate what 'non-obtrusiveness' means! You don't depend upon the container apis as much as perhaps Spring or other IoC containers out there.

    For the record, the Spring container is as non-intrusive as a lightweight container can possibly be. In particular, Pico-style constructor injection is fully supported in Spring as well, with arguably even more sophistication than found in Pico (with optional argument conversion etc).

    Components running in Spring usually don't have *any* dependencies on container APIs. We even support non-typical ways of object instantiation (factory methods etc) and components with abstract lookup methods (avoiding container API dependencies even for creating prototype instances).

    Juergen
  17. Geronimo Gbean Architecture[ Go to top ]

    Hani...is that you?