Tech Talk: Bruce Tate on EJB 3, Lightweight Containers, AOP

Discussions

News: Tech Talk: Bruce Tate on EJB 3, Lightweight Containers, AOP

  1. In this interview, Bruce Tate talks about EJB 3, praises it for its simplicity and transparency, but expresses concern about container lock-in via annotations. He looks at the advantages of lightweight containers such as Spring, and stresses that we focus on services, not containers. He also gives his thoughts on the future of AOP, and talks about his new book, 'Better, Faster, Lighter Java'.

    Bruce Tate on AOP
    "AOP is going to happen. The timing of AOP is no accident. New paradigms do not emerge because they're cool or new. They emerge because we need them. Every 20 or so years, the current paradigm runs out of gas, like OOP is today.

    But at first, AOP going to happen badly. Think back to the early days of OOP. We all learned that if we were to have any hope of reuse, then we had to use inheritance, and use it liberally. That thinking was flat out wrong. Inheritance is best used sparingly, but with tremendous impact. Aspects will be the same. Early adopters are already using AOP, and with good success. People like my friend Ramnivas Laddad are already using AspectJ to solve real problems, and solve them well.

    But object technology adoption was very slow. We started with SmallTalk, which never achieved commercial success. Then, we moved to C++, which was commercially successful, but not really pressed as an object oriented language. In many ways, we had C++ --, meaning we were writing procedural code with an object oriented language. Microsoft tried to sell COM with C as an object oriented platform, but it did not support true inheritance. Still, we were learning as an industry. Those ideas accumulated momentum and mass, so that when the planets aligned, OOP exploded with Java. AOP will be no different. We're going to have to learn, and experience success, and lots of failure, before it's actually applied in the main stream. Tools that cross over, like Spring, AspectJ, and Pico, will have tremendous impact, much like crossover languages did for OOP. Ada introduced encapsulation. Visual Basic introduced component models. C++ let procedural code and OO code live side by side. We'll see this history repeat itself.

    But I think that we're first going to have to simplify, and strip off a whole lot of dead weight, before we're going to be ready for AOP, becuase it's not yet time. And that's why Better, Faster, Lighter Java is such an important book.
    "
    Read Bruce Tate's Interview

    Threaded Messages (88)

  2. Still gas in the tank[ Go to top ]

    Let's make it clear...AOP is not a replacement for OOP, but rather a compliment to it. Not even the AOP zealots like myself say that AOP is going to replace OOP.

    Personally, I think smart and correct usage of annotations will be far more import in "stripping the dead weight from Java" than any IoC/Dependency Injection framework. These IoC frameworks are nothing more that a replacement of one standardized XML deployment descriptor(EJB), with another, albeit, simpler XML non-standardized deployment descriptor. Annotations combined with code generation, or even better, AOP give a much better a simpler way of simplifying things for developers.

    Bill
  3. IoC is a design principle[ Go to top ]

    IoC is a design principle that decouples your components and allows testing in isolation. An IoC container like Spring allows you too apply this design principle, with all its advantages, consistently to your business modell. How the container achieves is not the main point. This can be achieved via XML or even via AOP.
    These IoC frameworks are nothing more that a replacement of one standardized XML deployment descriptor(EJB), with another, albeit, simpler XML non-standardized deployment descriptor.
    This statement misses completely the point and importance of IoC containers.
  4. IoC is a design principle that decouples your components and allows testing in isolation. An IoC container like Spring allows you too apply this design principle, with all its advantages, consistently to your business modell. How the container achieves is not the main point. This can be achieved via XML or even via AOP.
    These IoC frameworks are nothing more that a replacement of one standardized XML deployment descriptor(EJB), with another, albeit, simpler XML non-standardized deployment descriptor.
    This statement misses completely the point and importance of IoC containers.
    Simple inventions can be the most powerful, and the easiest to miss.
  5. Simple[ Go to top ]

    These IoC frameworks are nothing more that a replacement of one standardized XML deployment descriptor(EJB), with another, albeit, simpler XML non-standardized deployment descriptor.
    This statement misses completely the point and importance of IoC containers.
    Simple inventions can be the most powerful, and the easiest to miss.
    It is very rare that simple inventions are powerful. Indeed, dependency injection is an example of a useful simple invention that is simply not that powerful.

    Sure, it is very nice, extremely elegant. But it doesn't solve any very difficult problem. It's certainly a great idea, but it's also being massively, horribly oversold here.

    Guys, back to reality: Java projects do not fail because of needing to type "new InitialContext().lookup()". We have much, much bigger fish to fry, starting with the mess that is the presentation tier.
  6. Simple[ Go to top ]

    Guys, back to reality: Java projects do not fail because of needing to type "new InitialContext().lookup()". We have much, much bigger fish to fry, starting with the mess that is the presentation tier.
    Yes, this stuff known as IoC can not improve performance, security or something important. I see no major difference in lookup ( service finds component or component finds service). "Lookup" vs "Inject" is the mater of taste and I do not think both are cool. IoC container just builds object graph from XML file,it is extended DOM builder, is not it ?
  7. Re: "taste"[ Go to top ]

    "Lookup" vs "Inject" is the mater of taste...
    Returning an int error code from a function or raising/throwing an exception also can be seen as a matter of taste, yet arguably the latter produces much more clean and maintainable code. IMHO "lookup" vs "inject" predicament looks somewhat similar to "error code" vs "exception" dilemma, is it not? ;-)
  8. Re: "taste"[ Go to top ]

    "lookup" vs "inject" predicament looks somewhat similar to "error code" vs "exception" dilemma, is it not? ;-)
    Indeed. But I am quite happy with "lookup" (for now).
    public class MyCustomerBean {
        protected DataSource custDS;

        public MyCustomerBean() throws Exception {
           Properties props = .. // load config properties
           String dsname = props.getProperty("customer.datasource", "CUST");
           InitialContext ctx = new InitialContext();
           custDS = (DataSource) ctx.lookup(dsname);
        }
    ..
    }
    My constructor body defines what it takes to create this object. Anything goes wrong, exception is thrown and object won't be created. Simple.

    I agree that it is not pure OO and will be cleaner if the dependency objects are passed through the constructor (constructor injection). But it would get ugly if I have a lot of dependencies. A constructor with a dozen parameters.. nahh

    I wish we had a better alternative than Properties to get configuration data. (EJBContext is no better).
  9. Re: "taste"[ Go to top ]

    public class MyCustomerBean { protected DataSource custDS; public MyCustomerBean() throws Exception { Properties props = .. // load config properties String dsname = props.getProperty("customer.datasource", "CUST"); InitialContext ctx = new InitialContext(); custDS = (DataSource) ctx.lookup(dsname); }..}
    My constructor body defines what it takes to create this object. Anything goes wrong, exception is thrown and object won't be created. Simple.I agree that it is not pure OO and will be cleaner if the dependency objects are passed through the constructor (constructor injection). But it would get ugly if I have a lot of dependencies. A constructor with a dozen parameters.. nahhI wish we had a better alternative than Properties to get configuration data. (EJBContext is no better).Hi Sutanu,

    Correct me if I am wrong, this lookup code will need to be in many other places as well, i guess, why not have it in using a get/setMyDatasource and configure the datasource in Spring's applicationContext. This way, i guess, changing the datasource would be in one place. Or extends from one of the AbstractXXXBeans in Spring (it is an ejb isn't it?).

    best regards.
  10. Re: "taste"[ Go to top ]

    "clean and maintainable code" is the mater of taste, some people think checked exeptions clears it ... . There is nothing wrong in JNDI, it is possible to use it in the wrong way, but I am sure it is possible to implement crap using spring too.

    Problem is not in "injection" or in "lookup", problem is in EJB container design, there is no way to register component, it decides how to deploy all components. It is very easy to solve this problem, but EJB experts started to thing about IoC stuff, container can live without IoC and I can implement it myself, just let me to do it in container :

    MyAppLifeCycle implements AppLifeCycle{


      void start( Server server ){

        server.registerStatelesSessionBean( new MyBean( new MyDataSource() ) );

      }


    }
  11. Re: "taste"[ Go to top ]

    BTW EJB server is not a component container, EJB is an application framework and not a good one. Component oriented programming is very trivial and there are a lot of good examples, ActiveX is a good one, JAVA applets and JAVA servlets are good component oriented programming example too. There is nothing to invent and there is no need to fix JNDI.
  12. Simple[ Go to top ]

    [IoC is] certainly a great idea, but it's also being massively, horribly oversold here.Guys, back to reality: Java projects do not fail because of needing to type "new InitialContext().lookup()". We have much, much bigger fish to fry, starting with the mess that is the presentation tier.
    Gavin, I certainly don't disagree with your last sentence - but this is underselling IoC. I found that it did much more to my team's software than eliminate "new InitialContext().lookup()". What we do with the IoC container is much richer and finer grained than we ever did with JNDI or anything else. As simple as dependency injection is, it profoundly impacted our design, implementation, testing, and levels of reuse.
  13. Simple[ Go to top ]

    +1
  14. Simple[ Go to top ]

    +1

    I am a 36 y.o developer who went from assembly to basic to C to C++ (true object oriented usage, and heavy use of STL to produce WindowsNT AND Solaris portable code, with only 3 classes over 200 being OS aware, / versus \ anyone ?). Of course i also use SQL and Corba now playing with JMS to build enterprise wide applications and services.

    What i DO want is somethink that :
    -makes my life easier during development in the sens that all repetitive and cumbersome tasks are automatically handled (either using a code generator, such as VisualC++ wizards or Aspects, i don't care, as far as the result is readable and understandable by a human person with standard memory and CPU ;o)
    -makes my life easier during development by providing good bulletproof standard libraries, possibly thread-safe from start, so that bugs in the project will be mine, not someone else's, and i don't have extra-money for solving my own bugs;
    -makes my life easier for maintenance, as i hate receiving a call during the week-end because of software catastrophic failure, so testing is really important here;

    Because in the end, i have a business requirement, and i want to focus on the efficient algorithms that i will be implementing, because in the end i give a "black box" to my boss, and i will be judge on factors that are simply not technical, not at all, such as delivery time, downtime, price of the solution (including harware price).

    But i am getting more and more tired of learning new lamguages, new working environments, even new OS's shells. I am not having a better productivity here, i am having a worse. Because i have to learn these new languages, and i have to experiment with their limits, and i will be for some months or years under-using or mis-using them. Of course i will be more productive after a while, but then a new technology is introduced, and i have to switch again. Highly risky, unless the changes introduced are simple although powerful.

    So, in the end, i like Java. One simple object oriented compiled language with portable standard libraries, possibly interpreted (i.e Javascript) if necessary, and very easy to read, so to maintain, thanks to the stacktrace. A language so simple Microsoft had to copy its principles very quickly not to loose their developer base (good move M Gates, your company is really agile...). And efficient enough, thanks to JIT compiler.

    I don't use EJB although i can understand their use in some specific projects which are quite rare (for me), such as those needing a transaction monitor, or access to legacy database with no jdbc driver, because they were really breaking the object oriented paradigm. Such a bad try to bring CORBA (i.e distributed services) features to J2EE.

    And i like AOP + IoC + JDO, the more i study them the more i like them. Because i do have simple business objects now (simple as a "struct" linked list in C with some well located code for behaviour), thanks to JDO. Plus a flexible way to add/plug cross-concern behaviour to my business objects that keep being simple, though readable, thanks to AOP. And my objects can be easily used for prototyping or testing, thanks to IoC. All this without having to learn a brand new language or a complex tool, only some simple external XML configuration file syntax which does not mix mithin my own code. I buy it. Simplicity, this is all about it. What i was doing in my Main method before, i.e build my objects and their relationship before starting the process, i can do it now via external XML file which is more flexible from my point-of-view.

    As an exemple, i am playing with AOP now to add profiling to an existing java appication, so i know where to optimise it, without impacting the already existing business code. The preliminary results are fantastic regarding the simplicity, and it is all Java + some external metadata. How could i easily do it if my code was running into a J2EE application server (JBoss, Websphere or Weblogic or xyz) ? With ANY Java runtime engine ? Even if i could be doing it, i would be at least limited by the container, wouldn't i ? (Well, i am not sure on that point...)

    Regarding annotations, although they seem useful, i am afraid they will put vendor lock-in within the code. I greatly prefer parameters or vendor specific stuff (any metadata in fact...) to be oustide of my own code, an XML file is perfect for that, because of the inherent structuration of its content. About the same reason why all constants in C and C++ were expressed as "#define" expressions in the very begining of the header file (good practice...), not in the code file.

    Regarding object distributions, i stick now with JMS for inter-process communication. Sooooooo flexible, so little overhead compared to... database processing time for instance. As far as your network is not overloaded, of course, but if it is you're dead anyway...

    So thanks to Sun for promoting Java, and keeping it consistant (please don't add nothing exotic to it apart from real templates, we are already seeing the bad side effects of autoboxing, for instance, just to save one cast !!!!!). And i do really hope they will get more benefits (i.e $$$) from this achievement, as i believe they do deserve it. Too bad they do not produce better development tools.

    Cheers,

    Christian
  15. Simple[ Go to top ]

    In your former life (before JBoss) you had a different opinion.

    http://www.theserverside.com/news/thread.tss?thread_id=20229#88350
  16. Simple[ Go to top ]

    In your former life (before JBoss) you had a different opinion.http://www.theserverside.com/news/thread.tss?thread_id=20229#88350
    Sorry, the wrong link!

    The correct one is:

    http://www.theserverside.com/news/thread.tss?thread_id=20229#88550
  17. Simple[ Go to top ]

    Probably I do not get it, but I think it is too trivial to discuss. Can somebody explain it. How it is better than factory "ConnectionFactory.getConnection()"
     or contract "setContext(Context context)" ?
  18. Ioc - Why it's better[ Go to top ]

    Here's why I think Ioc is better than:
    ConnectionFactory.getConnection()
    Here's what usually happens when you have code that looks like the above: You start off making your connection factory return regular jdbc connections. Next you realise you want to deploy the same component in a container and you want to use a datasource but somewhere else, you want to get the connection from a Hibernate session factory. So you're faced with either replacing the ConnectionFactory or making it configurable. But do you make it configurable by having a properties file, an xml file, a database, jndi. Should it use the same kind of configuration that all your other factories use? How do you supply a different connection for a specific unit test (ConnectionFactory.setConnection()?). Now, each of those problems could be solved reasonably sensibly but you'll end up writing a framework and your code will be dependent on it. Which means that if you want to ship it off to a third party, they'll have to use your framework for putting it together, which may not even be compatible with their framework for putting things together.

    if on the other hand, you use:

    setConnection(Connection connection), it doesn't imply any kind of framework. You could use Spring and it's XML configuration or you could just call it using Java (ps. to everyone, XML and IoC are not joined at the hip, IoC component work just fine configured from regular Java).
    setContext(Context context)
    This is a little different because this is an example of IoC anyway. The advantage of using setConnection(Connection connection), if that's all you need from the context, is that it more clearly defines the component's dependencies. You'll also find yourself having to hardcode/configure the name of the connection in the context in your component. If you hardcode it you're stuck if someone else accidentally used the same name. If you configure it, you're back to how you get THAT property into your object (setContextConnectionName(...)?).
    InitialContext.lookup(...)
    JNDI does solve the framework problem mentioned earlier because at least it's standard. It doesn't solve the naming problem and it also reduces the visibility of what the components requirements are. Testing is also messy because you have to then set your test services into the context and then remove them after each run.
  19. Ioc - Why it's better[ Go to top ]

    Ok, I probably understand it. It looks like a contract without interface declaration, Are java beans "get/set" or Serialization with "writeReplace" IoC too ? Why do you need "clever" names for trivial things ?
  20. Ioc - Why it's better[ Go to top ]

    It looks like a contract without interface declaration
    It is a contract and this is why the Pico guys like using the constructor for IoC because it's a better way of distinguishing the dependencies required for a component vs. it's attributes.
    Are java beans "get/set" or Serialization with "writeReplace" IoC too?
    Setter based IoC uses the java bean's style methods. This means that almost any Java Bean (or POJO) is a candidate IoC component. Not so sure about "writeReplace", though.
    Why do you need "clever" names for trivial things?
    Never underestimate the power of naming things. Design patterns gain much of their usefulness because they name concepts. That IoC could be considered an alternative to your ConnectionFactory example means that it has to be a pattern too (and thus at least useful in discussion, e.g. "Should we use a Factory to look up the connection or should we use Dependency Injection").
  21. oh noooooo, you caught me out....[ Go to top ]

    In your former life (before JBoss) you had a different opinion.
    Actually, I have not changed my opinion. I thought IoC was great then, I think it's great now. Back then, it was not being sold as a panacea. Now it is being sold that way (by some people).

    Oh and by the way, intellectually honest people change their opinion sometimes. In the past year I've changed my mind about *lots* of things. (It just happens that this is not one of them.)

    That was a *very* childish comment.
  22. Oversold[ Go to top ]

    At its base level, I think IoC buys us a lot. Every OO book/pattern/whatever encourages decoupling by programming to interfaces. On the surface this is a great idea. In practice it is not that easy. An object has to have a way to get an concrete instance somehow.

    EJB has a built in model for that - JNDI lookup. It is a little messy - most of us abstract that out into a lookup object that does all the JNDI stuff for us. But we still have an active lookup in our objects, which makes testing tricky.

    But what about other objects? What about services we write that are not EJBs. We should still access them through interfaces, right? So we need some locator/factory to obtain these instances. So we have to end up inventing some way to configure this look up.

    For a quick example, say we have a class that needs to time out something after a certain period of time is passed. An easy way to do this is to have a instance variable that has the time out specified, and then compare this to the current time. How do we get the current time - System.currentTimeMillis(). But if we hard code this into our class, it makes testing difficult. Very short times would be hard to test accurately, while long times would kill a test cycle.

    So we create an interface, say TimeProvider, that has one method: getCurrentTime(). Our implementation would just delegate to System.currentTimeMillis(). But we could easily mock this object for the sake of good testing. Now that we have an interface, we have to get an instance. If we want to actively look up this object, we have to create some sort of a factory. For testing, we have to appropiately configure this factory as well. What a pain. This pain makes developers want to avoid doing things the "right" way.

    Using Spring, I just wire in my concrete implementation for my application and mock the interface for my tests. So much easier. Making programming the "right" way easier has tremedous payback. So maybe the problem being solved (dependency management) is not as complex as others. But solving this problem enables developers to write good code easier. That is extremely important.

    And one more things - Spring has a proprietary configuration file. So what? Hibernate was a proprietary configuration. It's doing fine. Log4J has proprietary configurations. Everybody seems to use it. If the tool has value and the configuration is intuitive (Spring's is very intuitive) people will use it. EJB 3 has no value for me at this time because it doesn't exist yet. Until then, I will happily use Spring.

    Ryan
  23. Dependency Injection[ Go to top ]

    But what about other objects? What about services we write that are not EJBs. We should still access them through interfaces, right? So we need some locator/factory to obtain these instances. So we have to end up inventing some way to configure this look up.
    Indeed. Once you decide that Dependency Injection is a Good Thing, why stop at objects sourced from JNDI, which appears to be as far as the EJB3 model goes? True IoC containers allow you, the developer, to decide on the granularity of the objects you want to manage. They might even be legacy classes, configured via constructors or JavaBean properties, which know nothing of the latest and greatest annotations. (Indeed, they may--heaven forbid--have been written without the advantages of J2SE 1.5, and the necessary annotations.)

    EJB3 is not a general-purpose IoC solution, comparable to Spring, PicoContainer and HiveMind in the IoC space. Hence it's completely wrong to claim that IoC containers are "nothing more that a replacement of one standardized XML deployment descriptor(EJB), with another, albeit, simpler XML non-standardized deployment descriptor." If you look at the text in Chapter 4 of Expert One-on-One Design and Development describing the motivation for Spring's IoC container, you'll see that it had little to do with replacing the EJB component model, and everything to do with replacing the mishmash of configuration strategies found in typical J2EE apps. Yes, we do argue that Spring provides a good EJB alternative in many scenarios. But that involves far more Spring services than just IoC, such as AOP features (for declarative transaction management) and Spring's transaction management abstraction.

    Regards
    Rod
  24. Simplicty[ Go to top ]

    It's certainly a great idea, but it's also being massively, horribly oversold here. Guys, back to reality: Java projects do not fail because of needing to type "new InitialContext().lookup()". We have much, much bigger fish to fry, starting with the mess that is the presentation tier.
    Projects fail because the succumb to entropy (among other reasons). The individual bits and pieces just stop working together. Maybe it compiles, but it doesn't run (or doesn't run well enough and fast enough). You hit a bug and waste hours and days tracking it down.

    Using heavyweight technologies, like JNDI, to connect simple java beans is a principal problem.

    If Sun's JNDI interface had been factory based, with an acknowledgment that it should be easily "hookable" for testing purposes, then there would be less of a need for simpler solutions.

    However, "new InitialContext()" is a huge problem, because it ties code to JNDI, and thus, to the full EJB container.

    What I'm finding is that I tend to use large numbers (i.e., dozens or more) of tiny services ... usually, just one or two methods each. I'm using HiveMind, but the same appoach applies to all the lightweight containers. I can build real tests for my tiny, simpe service implementation and know that my code works, no muss, no fuss.

    HiveMind/Spring/etc. today vs. EJB 2.x today is a no brainer. The incremental cost of adding a new service using IoC is tiny, whereas (even with XDoclet and friends) the incremental cost of adding a new service to EJB is high. Thus, IoC promotes a better design (small, simple objects) and EJB promotes a more monolithic design.

    To me, this parallels the transition from C (and, for me, Objective-C) to Java. The memory management issues in Objective-C promoted the use of very, very large objects (fewer allocations, fewer retain cycle headaches). Java, with garbage collections, promotes a fine grained approach using large numbers of simple objects. I'm much happier in the Java world than in the Objective-C world ... and much happer in the IoC world than the EJB world.

    Oh, and I'm pretty happy with at least one presentation tier solution!
  25. JNDI[ Go to top ]

    Using heavyweight technologies, like JNDI, to connect simple java beans is a principal problem. If Sun's JNDI interface had been factory based, with an acknowledgment that it should be easily "hookable" for testing purposes, then there would be less of a need for simpler solutions.However, "new InitialContext()" is a huge problem, because it ties code to JNDI, and thus, to the full EJB container.
    Howard, this is disingenious. JNDI is *not* a heavyweight technology and does *not* tie you to a J2EE container. Sun's filesystem provider is a few k, and in the past I have written a pure-memory JNDI provider for testing (it was trivial).

    Of course, depenedency injection is much nicer than the registry pattern. No-one seems to argue otherwise. I am *not* attacking IoC. Really. I think it's just great. And I agree with what you say about it enabling a finer grained OO style, which is definitely also one of the things that motivated the design of Hibernate.

    All I'm saying is that it does not seem to solve any of the really Big Problems that I've wrestled with when developing Java applications. I dunno, perhaps JNDI has been a major problem for some people; it has never been for me personally....
    Oh, and I'm pretty happy with at least one presentation tier solution!
    :-)

    I am reading your book now....
  26. JNDI[ Go to top ]

    I have read article about Spring AOP and I see it uses lookup itself.
    "InitialContext" is replaced by "ApplicationContext", "ctx.lookup" is replaced by "ctx.getBean", is it bug in article or Spring directory interface is better than JNDI ?

    import org.springframework.context.ApplicationContext;
    import org.springframework.context.support.FileSystemXmlApplicationContext;

    public class MainApplication
    {
        public static void main(String [] args)
        {
            // Read the configuration file
            ApplicationContext ctx =
              new FileSystemXmlApplicationContext(
                "springconfig.xml");

            //Instantiate an object
            IBusinessLogic testObject =
              (IBusinessLogic) ctx.getBean("businesslogicbean");

            // Execute the public
            // method of the bean
            testObject.foo();
        }
    }
  27. JNDI[ Go to top ]

    I have read article about Spring AOP and I see it uses lookup itself."InitialContext" is replaced by "ApplicationContext", "ctx.lookup" is replaced by "ctx.getBean", is it bug in article or Spring directory interface is better than JNDI ?
    Juozas, what you are referring to is standalone startup code. Facades always need to fetched from a context in a lookup fashion there, as the startup code itself is not managed through depenency injection. Within the Spring context, all objects are managed through injection rather than lookup, for example: business facades, data access objects, resource factories, etc. None of those objects needs to code a lookup itself.

    In environments like a web app, you can even have no lookup at all in an entire application: If the entry points are Spring-managed beans themselves (like Spring web Controllers or Struts Actions via the Struts plugin) or can declaratively refer to Spring beans by name (like with WebWork2's external references or JSF's managed beans), everything can get wired through dependency injection.

    Juergen
  28. Very well said.
  29. Simplicty[ Go to top ]

    The folks at resin have some interesting idea's

    http://www.caucho.com/resin-3.0/protocols/tutorial/hessian-ioc/index.xtp

    combining the power of jndi with the testability of ioc, too bad it would lock you in to resin from the looks of it
  30. Simplicty[ Go to top ]

    The folks at resin have some interesting idea'shttp://www.caucho.com/resin-3.0/protocols/tutorial/hessian-ioc/index.xtpcombining the power of jndi with the testability of ioc, too bad it would lock you in to resin from the looks of it
    Note that Spring includes explicit support for Caucho's Hessian and Burlap protocols, both for the server side and the client side. Exporting a Spring-managed bean as remote service via Hessian and/or Burlap is straightforward, as is wiring client-side application objects with Hessian/Burlap proxies.

    This gives you the full power of both Spring's dependency injection and Hessian's/Burlap's lightweight remoting. For an example, see Spring's JPetStore: It exports its OrderService via 4 different remoting protocols, and also includes a demo client that does remote access via all of those protocols.

    Juergen
  31. average java programmer[ Go to top ]

    It is very rare that simple inventions are powerful. Indeed, dependency injection is an example of a useful simple invention that is simply not that powerful.Sure, it is very nice, extremely elegant. But it doesn't solve any very difficult problem. It's certainly a great idea, but it's also being massively, horribly oversold here.Guys, back to reality: Java projects do not fail because of needing to type "new InitialContext().lookup()". We have much, much bigger fish to fry, starting with the mess that is the presentation tier.
    Hibernate is incredible and my hats off to you, but I don't think you understand the mind of the average Java programmer-like myself. IoC and Spring in particular make life much easier.
    Have one average java programmer sit down and configure Spring w/ Hibernate and have another sit down and configure JBoss and you'll see Spring is much easier. In my opinion Spring and IoC is a big advance in the Java community.
  32. Simple[ Go to top ]

    Indeed, dependency injection is an example of a useful simple invention that is simply not that powerful.Sure, it is very nice, extremely elegant. But it doesn't solve any very difficult problem. It's certainly a great idea, but it's also being massively, horribly oversold here.Guys, back to reality: Java projects do not fail because of needing to type "new InitialContext().lookup()". We have much, much bigger fish to fry, starting with the mess that is the presentation tier.
    Actually, in my experience "new InitialContext().lookup()" is a cross-cutting concern, or at least as soon as you start passing one or more configuration options into the created context (as pointed out by Howard in this thread). IoC, in my case PicoContainer, can centralize this cross-cutting concern into one place which to me is a huge help.

    This is perhaps not "big fish" for tutorial examples, or trivial tests, but once you start doing large apps, where "new InitialContext().lookup()" with all the extra configuration code is done >1000 times, it becomes a monstrosity.

    Think of it as death by being bitten by a horde of tiny ants. Each ant is harmless, but together they pack a punch to be considered.
  33. Simple inventions...[ Go to top ]

    IoC is a design principle that decouples your components and allows testing in isolation. An IoC container like Spring allows you too apply this design principle, with all its advantages, consistently to your business modell. How the container achieves is not the main point. This can be achieved via XML or even via AOP.
    These IoC frameworks are nothing more that a replacement of one standardized XML deployment descriptor(EJB), with another, albeit, simpler XML non-standardized deployment descriptor.
    This statement misses completely the point and importance of IoC containers.
    Simple inventions can be the most powerful, and the easiest to miss.
    Ah, I must keep my blood pressure down early in the morning. Sure IoC is a "simple invention". One might argue however that it is not an invention after all. All it is is typesafe, external configuration, something that is neither new nor particular thrilling. I am still totally missing the point of the hype of IoC, other than that it may be a bit easier to run tests on it that with EJBs. Sigh!

    As for the "simple inventions" after all... Well, we all thought EJBs were a simple invention, Web Services were simple inventions, CORBA was a simple invention, oh and object orientation was a simple invention (let alone SQL). Well it turned out for them to be of real value in enterprise computing they needed to morph into pretty complex beasts, which is exactly where all the IoC containers are currently heading.

    Anyway, most efforts that I see nowadays aiming at reducing complexity are actually increasing it, from framworks to tools (like strange GUI builders springing up all over the place) to support tools (like the famous, "hey maven can do for you almost what make could do for you 20 years ago, but we added a new language and a new document format to make things a little less transparent") to domain misuse ("Yeah AOP is great for technical cross cutting concerns, so lets go about using it for all out business functionality as well").

    There are only very few exception, like proper service and component oriented programming. But I have the distinct feeling that this is plainly not exiting enough.
  34. Simple inventions...[ Go to top ]

    IoC is a design principle that decouples your components and allows testing in isolation. An IoC container like Spring allows you too apply this design principle, with all its advantages, consistently to your business modell. How the container achieves is not the main point. This can be achieved via XML or even via AOP.
    These IoC frameworks are nothing more that a replacement of one standardized XML deployment descriptor(EJB), with another, albeit, simpler XML non-standardized deployment descriptor.
    This statement misses completely the point and importance of IoC containers.
    Simple inventions can be the most powerful, and the easiest to miss.
    Ah, I must keep my blood pressure down early in the morning. Sure IoC is a "simple invention". One might argue however that it is not an invention after all. All it is is typesafe, external configuration, something that is neither new nor particular thrilling. I am still totally missing the point of the hype of IoC, other than that it may be a bit easier to run tests on it that with EJBs. Sigh! As for the "simple inventions" after all... Well, we all thought EJBs were a simple invention, Web Services were simple inventions, CORBA was a simple invention, oh and object orientation was a simple invention (let alone SQL). Well it turned out for them to be of real value in enterprise computing they needed to morph into pretty complex beasts, which is exactly where all the IoC containers are currently heading. Anyway, most efforts that I see nowadays aiming at reducing complexity are actually increasing it, from framworks to tools (like strange GUI builders springing up all over the place) to support tools (like the famous, "hey maven can do for you almost what make could do for you 20 years ago, but we added a new language and a new document format to make things a little less transparent") to domain misuse ("Yeah AOP is great for technical cross cutting concerns, so lets go about using it for all out business functionality as well").There are only very few exception, like proper service and component oriented programming. But I have the distinct feeling that this is plainly not exiting enough.
    Agree with you!!

    It seems now people are more interested in building framework after framework. Everybody is claiming now easy to use their framework, now light weight, how closely it has implemented IoC, Dependency injection idea etc etc.

    And some one comes up, builds another framework, which will make your client code independent of all these frameworks. If you use my framework X, you can use any framework for persistence. etc etc....

    Java is in crisis. And AOP is going to change the world. Its going to bring long lasting happiness to the greater universe. Martians, better watch out! AOP is reaching there!!!

    Sigh!!!!
  35. IoC is a design principle[ Go to top ]

    You miss Bill's main point.

    Decoupling components is the design principle.
    Even the IoC implementations can't agree on how you then couple them,
    though some are less intrusive than others.

    Repeating Bill's main point:
    What is interesting is the metadata (in the form of annotations)
    that defines your required behaviour.

    Before you start moaning, annotations should also be external to the
    class file and standardized (plain common sense and on the todo list
    of EJB3).

    @Inject Datasource dataSource;
    @Tx(@TxType.REQUIRED) public void thisMethodNeedsATransaction() { ... }

    This is what is important to developers. They couldn't care less
    how the container actually initialises the DataSource or that the
    @Tx annotation weaves in a transaction demarcation aspect.
    If they do care, it is what is the quality of implementation of that aspect
    and maybe for the experienced developers can they write their own?

    We at JBoss have argued from the beginning that JBoss/AOP (the container)
    isn't that important, it is just a vehicle to get at
    what is important, JBoss/Aspects (the aspect implementations).

    Bill asks what does an IoC container bring to the table?
    It has a proprietory configuration file and the service/aspect implementations
    generally delegate to somebody else's project or application server
    services.

    Bill argues why use proprietory when you can use a standard?
    EJB3 is just the first that is applying/standardizing this.
    Quite rightly it credits the IoC community for the ideas.

    I'd suggest if you have issues with EJB3 you get involved,
    before the big bad nasty vendors take it in a direction you don't want to go. :-)

    Regards,
    Adrian
  36. IoC is a design principle[ Go to top ]

    You miss Bill's main point.Decoupling components is the design principle. ... Bill asks what does an IoC container bring to the table?It has a proprietory configuration file and the service/aspect implementations generally delegate to somebody else's project or application serverservices
    I think you are mixing two very different things. That is IoC and AOP. Design principles have different levels of abstraction. You say that 'decoupling' is the important design principle. I agree, but it is a very high level one, and the question is how to decouple?
    Both, IoC and AOP, is about decoupling, but in different ways. AOP is about a strong decoupling of crosscutting concerns. It is a replacement for IoC, where IoC has been used to implement crosscutting concerns. But IoC is also an essential design principle to achieve decoupling within your business modell. That is where you have no crosscutting concerns (we have decoupled them with AOP) and where OOP is the only player. This is the place where you have to think about stupid things like customers, addresses and shopping carts. And for modelling this stuff, IoC (or the stronger version, the Dependency Inversion Principle) is very important. An IoC container makes it easy to apply these principles to your business modell.

    Don't be confused by the many faces of the spring framework. Spring is an IoC container but also enables AOP. We are talking about IoC here.
     
    Even the IoC implementations can't agree on how you then couple them,though some are less intrusive than others.
    Do you mean by that the discussion about what type of IoC to use (e.g. setter or constructor based)? If so, that would be a ridiculous point. The type of IoC is a very minor issue.
    Quite rightly it credits the IoC community for the ideas.I'd suggest if you have issues with EJB3 you get involved,before the big bad nasty vendors take it in a direction you don't want to go. :-)Regards,Adrian
    My impression is that neither you nor Bill appears to understand the core idea of IoC.
  37. hehe[ Go to top ]

    My impression is that neither you nor Bill appears to understand the core idea of IoC.
    Happily, I am able to assure you that both Bill and Adrian comprehend the extremely simple idea of IoC. It's just not what they are trying to talk about here.
  38. hehe[ Go to top ]

    Happily, I am able to assure you that both Bill and Adrian comprehend the extremely simple idea of IoC. It's just not what they are trying to talk about here.
    The principle is obviously extremely simple. It is very difficult not to understand. But the implications are a bit more complex. And from what I've read here by Bill and Adrian, they are trying very hard to miss the point (may be intentionally, I don't know).

    Or do you second the following statements about IoC containers? (If so, I would be very happy, if you could explain them to me):
    These IoC frameworks are nothing more that a replacement of one standardized XML deployment descriptor(EJB), with another, albeit, simpler XML non-standardized deployment descriptor.
    Bill asks what does an IoC container bring to the table?
    It has a proprietory configuration file and the service/aspect implementations
    generally delegate to somebody else's project or application server
    services.

    Bill argues why use proprietory when you can use a standard?
    EJB3 is just the first that is applying/standardizing this.
    Quite rightly it credits the IoC community for the ideas.
  39. 'IoC' vs. 'IoC Frameworks'[ Go to top ]

    An admission: It took a long while for IoC's benefits to 'click' for me. I've yet to use it on a project, because the click was so long in coming. I am studying the springframework at the moment, though, because I am definitely going to use it on the next project.

    I don't think Bills post, however, indicates that it hasn't clicked for him. Just the opposite. He's not asking "What's so good about Inversion of Control?" He's asking "What's so good about the existing Inversion of Control frameworks?" Or, twisting words a bit, "If we support Inversion of Control in JBoss, why would someone still use these frameworks?" Or, better yet, "Which pieces of these frameworks are people really using, such that they should be incorporated into JBoss?"

    I'm not qualified, yet, to answer any of these. Anyone else?
  40. 'IoC' vs. 'IoC Frameworks'[ Go to top ]

    I don't think Bills post, however, indicates that it hasn't clicked for him. Just the opposite. He's not asking "What's so good about Inversion of Control?" He's asking "What's so good about the existing Inversion of Control frameworks?" Or, twisting words a bit, "If we support Inversion of Control in JBoss, why would someone still use these frameworks?"
    .......
     answer any of these. Anyone else?
    +1
  41. 'IoC' vs. 'IoC Frameworks'[ Go to top ]

    See http://www.theserverside.com/news/thread.tss?thread_id=27166#129081 about what Rod Johnson says about EJB 3 and Spring. EJB 3 is in its present state not about an IoC framework! It is about offering certain enterprise services to POJO's.
  42. 'IoC' vs. 'IoC Frameworks'[ Go to top ]

    An admission: It took a long while for IoC's benefits to 'click' for me. I've yet to use it on a project, because the click was so long in coming. I am studying the springframework at the moment, though, because I am definitely going to use it on the next project.I don't think Bills post, however, indicates that it hasn't clicked for him. Just the opposite. He's not asking "What's so good about Inversion of Control?" He's asking "What's so good about the existing Inversion of Control frameworks?" Or, twisting words a bit, "If we support Inversion of Control in JBoss, why would someone still use these frameworks?" Or, better yet, "Which pieces of these frameworks are people really using, such that they should be incorporated into JBoss?"I'm not qualified, yet, to answer any of these. Anyone else?
    I should have left out my blurb about bashing IoC out of my comment. I just get annoyed that people tout it as this Holy Grail.

    The main focus of my comments was that JDK 5.0 annotations and, to a lesser extent, AOP, will have much much much much more effect on simplifying programming in Java than any of the current IoC frameworks can even hope to. Annotations and AOP bring so much power to framework and middleware developers than IoC ever will. Shit, combine the two (AOP + annotations) and you have something really powerful.

    As far as: "Which pieces of these frameworks are people really using, such that they should be incorporated into JBoss?" No, I wasn't asking that question. We've had IoC for years with our Microkernel. Don't believe me? Go download the 2 year old JBoss 3.0. Service lifecycle, simple POJOs with XMBeans, interception, classloading scoping, GUI management, remoteness, explicit dependencies, dependency injection, hotdeployment, component deployment abstractions, all available since 3.0. Many of our customers solely use our microkernel to develop applications.

    Bill
  43. 'IoC' vs. 'IoC Frameworks'[ Go to top ]

    Bill,

    Perhaps you can explain to us how JBoss makes testing outside of a container easier. The simple implementations of IoC do this. Surely JBoss allows for something like this, that's fairly easy to understand? Unless there's something I don't know about, it's not incredibly easy to test code with pieces of JBoss inside a JUnit test. Nothing as simple as PicoContainer.

    We are JBoss customers, and we enjoy it a lot, but one piece that I'm missing in your POJO vision is easy unit testing. I know you guys have thought about it. Please let us know what you're thinking.

    Steve
  44. testing[ Go to top ]

    Bill,Perhaps you can explain to us how JBoss makes testing outside of a container easier. The simple implementations of IoC do this. Surely JBoss allows for something like this, that's fairly easy to understand? Unless there's something I don't know about, it's not incredibly easy to test code with pieces of JBoss inside a JUnit test. Nothing as simple as PicoContainer.
    You should read my blog about EJB3.

    http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/07/05#ejb3part1

    Our EJB3 implementation will make it very easy to do out of container testing.
  45. 'IoC' vs. 'IoC Frameworks'[ Go to top ]

    Bill,Perhaps you can explain to us how JBoss makes testing outside of a container easier.
    I am not Bill, i just try to figure out an answer...

    As EJB 3 business objects will be POJO, they should be testable using any POJO testing methodology, in contrast to EJB 2. These POJO will still need to be glued together, though. Maybe using IoC based lightweight framework ? :o)

    And if they are testable outside of the J2EE application server, they will surely be deployable in production into these other containers. This is all good, as we will write business objects 100% independant from the underlying application server/container/how ever you call it. So we will be able to compare various J2EE based projects with non-J2EE (more or less lightweight) containers, and choose the one that best fits our need.

    I dream we could even compare CMP EJBs with their JDO counterparts, or anyother persistance mechanism (i am agnostic...) without changing a single line of the business object, only some external XML datafiles.

    Then everybody will be able to choose which technology best suit their needs, and even move from one to another during the lifetime of the application. This seems to good to be true !

    Christian
  46. Testing outside container[ Go to top ]

    I have failed to understand .. if I write a component that is ultimately destined to be running within a container, why I would test it outside the container?
  47. Testing outside container[ Go to top ]

    I have failed to understand .. if I write a component that is ultimately destined to be running within a container, why I would test it outside the container?
    For one, speed. If I want to unit test a new method I wrote or an existing method I changed, I don't want to have to fire up an entire container to do this.

    Ryan
  48. Testing outside container[ Go to top ]

    I have failed to understand .. if I write a component that is ultimately destined to be running within a container, why I would test it outside the container?
    Development speed for one. Having to cycle through the edit->compile->container startup adds up to quite a bit of time when you do it, say, 50(or more) times in a single day. Also, I don't like tying my code to EJBs. I have POJOs that are exposed remotely via a thin EJB layer. Or Web service layer if the need arises. That is one of the appealing features of Spring, to me anyway. I can still use declarative transaction *outside of the ejb container* for my day to day development and testing, then then I deploy it to the container, the functional testing within the container occurs.
  49. Testing outside container[ Go to top ]

    If I write a component that is ultimately destined to be running within a container, why I would test it outside the container?
    It's important to be able to test classes in isolation during unit testing. Of course you still need integration testing, but that's a different matter. Unit testing is very, very important.

    Recently I was involved with a project where there was a bug in some JDBC code. The developer would try to fix the problem, then redeploy the app to the container to see if it worked... Progress was naturally very slow. With a little redesign, we could test the JDBC code through a JUnit test, hitting the database, but without deployment to the app server. Round trips were so much faster that progress improved rapidly. A mock object approach, also outside the container, would also have been a good way to go.
  50. Testing outside container[ Go to top ]

    If Recently I was involved with a project where there was a bug in some JDBC code. The developer would try to fix the problem, then redeploy the app to the container to see if it worked... Progress was naturally very slow. With a little redesign, we could test the JDBC code through a JUnit test, hitting the database, but without deployment to the app server. Round trips were so much faster that progress improved rapidly.
    Nice say Rod, been through one of this senario and one will really really really really really appreciate the wieght-lifting Spring's provide. To be able to test individual component separately would be really really good.

    best regards
  51. Testing outside container[ Go to top ]

    If I write a component that is ultimately destined to be running within a container, why I would test it outside the container?
    It's important to be able to test classes in isolation during unit testing. Of course you still need integration testing, but that's a different matter. Unit testing is very, very important. Recently I was involved with a project where there was a bug in some JDBC code. The developer would try to fix the problem, then redeploy the app to the container to see if it worked... Progress was naturally very slow. With a little redesign, we could test the JDBC code through a JUnit test, hitting the database, but without deployment to the app server. Round trips were so much faster that progress improved rapidly. A mock object approach, also outside the container, would also have been a good way to go.
    Mock object approch is just way simpler if you use the container to do the plumbing.

    What I find funny about Spring is that is popular not becouse of its technical superiority but becouse it promises that you may use the same class as component inside the container and as ordinary class outside the container. This make some people think - OK I'll use Spring as I can always change my mind and escape. But IMO this will be just an initial transition and it needed for legacy stuff.
    But this is just a trap!
    Would you like now Rod to write application without Spring? I guess no.
    I bet once you are sold to the idea of containers there is no way back.
    Once people will choose COP they will want also more from the containers. E.g. they will be happy that Logging Services are provided by the container. Really setting up mock objects using the container is just way simpler then manual set up.

    Michal
  52. Testing outside container[ Go to top ]

    <blockquoteWhat I find funny about Spring is that is popular not becouse of its technical superiority but becouse it promises that you may use the same class as component inside the container and as ordinary class outside the container. This make some people think - OK I'll use Spring as I can always change my mind and escape. But IMO this will be just an initial transition and it needed for legacy stuff.There is much more power in such reusable components - this is by no means about legacy stuff. Spring allows you to reuse your business objects, data access objects, etc in any environment, be it in a Tomcat web app, behind a remote EJB facade, in a standalone application, or in a test suite.

    Consider an order management system: There might be both a web app version and a standalone Swing application for laptops (e.g. for sales representatives). Spring allows you to run the very same application objects in both environments, including middle tier services like declarative transactions.

    Spring is dedicated to all Java environments and does not concentrate on a single primary target environment. In contrast to this, EJB3 is still all about components for a J2EE server: It is not the intent of the EJB spec to make transaction and persistence services available outside an EJB container.

    Juergen
  53. Testing outside container[ Go to top ]

    <blockquoteWhat I find funny about Spring is that is popular not becouse of its technical superiority but becouse it promises that you may use the same class as component inside the container and as ordinary class outside the container. This make some people think - OK I'll use Spring as I can always change my mind and escape. But IMO this will be just an initial transition and it needed for legacy stuff.
    There is much more power in such reusable components - this is by no means about legacy stuff.</blacquote>

    I think you missed my point. My point was that what you described is what made spring popular and useful but this has just temporary value. There is something
    more valuable elsewhere on the horizon but probably still not that close

    There still will a need for such framwork like spring, but (correct me if I am wrong) power spring users are already further then you are showing it. They started to build application using native spring services and bound themselves to spring as they disoverd profits which are come from this. They are not any more writing "hacky-wacky" classes. They are writing classes having in mind the fact that those classes will be deployed to spring. They appriciate the fact that they can compose
    "business objects, data access objects, etc" in their application but if they have a choice they wold like to see those business object written using IoC and
    for example being capable to be integrated with spring transaction manager.Spring allows you to reuse your business objects, data access objects, etc in any environment, be it in a Tomcat web app, behind a remote EJB facade, in a standalone application, or in a test suite.Consider an order management system: There might be both a web app version and a standalone Swing application for laptops (e.g. for sales representatives). Spring allows you to run the very same application objects in both environments, including middle tier services like declarative transactions.Spring is dedicated to all Java environments and does not concentrate on a single primary target environment. In contrast to this, EJB3 is still all about components for a J2EE server: It is not the intent of the EJB spec to make transaction and persistence services available outside an EJB container.JuergenWhich is completly valid approch. EJB tries to standarize a component model.
    Spring is about something else and those things are not really overlapping.
    What's wrong is the fact that some people want to be able to use EJBs outside EJB container and assume that such approch has a real value. More matured component technologies are not about such "hacky-wacky" plumbing. If you really want to ever see component market (e.g for EJBs) the plumbing (contract between component and envinroment) must be well and precisly defined. Such contracts are
    the sign of maturity.

    Michal
  54. "tied"[ Go to top ]

    In contrast to this, EJB3 is still all about components for a J2EE server: It is not the intent of the EJB spec to make transaction and persistence services available outside an EJB container.Juergen
    Juergen, why do you keep repeating this, no matter how many times I correct you? :-(

    (1) EJB3 does not need to be "tied" to a full J2EE server - it is a *very* appropriate programming model for use in a colocated web tier, unit tests, a main method, etc.
    (2) I fully expect that there will be several "lightweight" EJB3 containers that may be embedded in Java applications, outside of an application server.
    (3) EJB3 components are no more "tied" to an EJB container than Spring components are "tied" to the Spring container. That is just plain disingenious.

    Look, you know how much I respect what you guys have done with Spring, but this is getting ridiculous. Please stop misrepresenting EJB3. If you have any questions about this issue, you know my email address, feel free to email me. I am quite happy to explain the intent of the spec in this area.

    It would be truly great to see you guys get behind the spec, or even involved in it.
  55. "tied"[ Go to top ]

    (3) EJB3 components are no more "tied" to an EJB container than Spring components are "tied" to the Spring container. That is just plain disingenious.
    How does this work? Aren't EJB3 components by definition "tied" to an EJB container? Can you explain a scenario where EJB3 components can be executed outside of an EJB container? And if so, what makes that runtime *not* an "EJB container"?
  56. "tied"[ Go to top ]

    (3) EJB3 components are no more "tied" to an EJB container than Spring components are "tied" to the Spring container. That is just plain disingenious.
    How does this work? Aren't EJB3 components by definition "tied" to an EJB container? Can you explain a scenario where EJB3 components can be executed outside of an EJB container? And if so, what makes that runtime *not* an "EJB container"?
    Any component must be tied to container. Component oriented architecture is nothing more than contract between container object and contained object. COP is more about configuration and customising than programming. So just drop COP and you will have IoC.
  57. "tied"[ Go to top ]

    BTW COP is very good for single user application, you can buy component and let monkey to configure and customise it, but it doe's not work on "server". EJB, CORBA, COM+ are all about COP, but all of them are not for monkeys and EJB 3 will be "complex" too. AOP is a powerfull thing for programmer, it is not for monkey, but monkey will never work on "server". So I think there is nothing bad to drop COP.
  58. "tied"[ Go to top ]

    (3) EJB3 components are no more "tied" to an EJB container than Spring components are "tied" to the Spring container. That is just plain disingenious.
    How does this work? Aren't EJB3 components by definition "tied" to an EJB container? Can you explain a scenario where EJB3 components can be executed outside of an EJB container? And if so, what makes that runtime *not* an "EJB container"?
    An EJB3 "component" is a JavaBean, just as a Spring component is. Rickard, have you actually read the spec???

    I can instantiate an EJB or spring component outside their respective containers, and invoke their methods. The scenario in which this is likely is unit testing.

    But my broader point is that EJB has a container, Spring has a container. This is not a differentiating feature.
  59. "tied"[ Go to top ]

    An EJB3 "component" is a JavaBean, just as a Spring component is.
    http://java.sun.com/docs/books/tutorial/javabeans/whatis/beanDefinition.html
  60. "tied"[ Go to top ]

    (3) EJB3 components are no more "tied" to an EJB container than Spring components are "tied" to the Spring container. That is just plain disingenious.
    How does this work? Aren't EJB3 components by definition "tied" to an EJB container? Can you explain a scenario where EJB3 components can be executed outside of an EJB container? And if so, what makes that runtime *not* an "EJB container"?
    Gavin didn't say that EJB3 components were *not* tied to an EJB container.

    He said they were "as tied" to an EJB3 container as Spring components are tied to the Spring container.

    It's so obvious that I'm surprised it deserves any further explanation. If you write a Spring XML configuration file to configure your beans and you want to run your application outside of Spring, you will still need some Spring-compatible runtime. Same with EJB3.

    --
    Cedric
  61. "tied"[ Go to top ]

    In contrast to this, EJB3 is still all about components for a J2EE server: It is not the intent of the EJB spec to make transaction and persistence services available outside an EJB container.Juergen
    Juergen, why do you keep repeating this, no matter how many times I correct you? :-(
    Look, Gavin, while you personally may see EJB3 as a generic component model for any Java environment, this is clearly not an obvious intent of the EJB spec. EJB is part of J2EE, for usage within a J2EE server. You may be the most active EJB3 representative in the community, but that does not make your personal opinion the official position of the EJB expert group or of all J2EE vendors.

    In particular, the only thing that will ever be J2EE-certified - according to the official EJB3 expert group position - is a full-blown EJB container shipped as part of a full J2EE server, which also has to provide EJB2 support. While standalone EJB3 containers without EJB2 support may be technically possible, they will never be certified as EJB-compliant.
    (1) EJB3 does not need to be "tied" to a full J2EE server - it is a *very* appropriate programming model for use in a colocated web tier, unit tests, a main method, etc.
    A colocated web tier is fine for EJB3 - as long as a colocated EJB container is available. For the others, you need a standalone EJB3 container that you deploy your components to - as an EJB jar. You need to start up that container, so that you can fetch your component proxies from it. Within that EJB3 container, your EJBs will run in a separate class loader, just like with EJB2.

    The other option is to create your EJB3 components as plain POJOs. You cannot apply transaction or persistence services then, though - your components need to be deployed to an EJB container to make those work. That usage style is neither suitable for integration tests nor for usage in standalone applications.
    (2) I fully expect that there will be several "lightweight" EJB3 containers that may be embedded in Java applications, outside of an application server.
    While this may happen in some fashion, I would be very surprised if this were covered by the EJB spec itself. The spec's programming and configuration model is clearly not intended for this: Standard EJBs need to be deployed as EJB jar and located via JNDI, and depend on JTA for transaction and persistence contexts. None of this infrastructure exists outside of a J2EE server.

    In particular, the EJB3 EntityManager does not provide means for local transactions but rather depends on a JTA environment, which makes it unsuitable for non-J2EE environments in the first place - in contrast to plain old Hibernate or JDO. I have raised this point numerous times - both in public and in private - but you have you not bothered to answer it yet.

    Of course, standalone EJB3-like containers may provide some additional API for (non-JTA) local transactions etc, but just in a proprietary fashion that is far from seamless. This is not what a generic component and O/R mapping model should result in. So why do you keep repeating that EJB3 will be oh so generic no matter how many times I raise these very valid points? :-(
    (3) EJB3 components are no more "tied" to an EJB container than Spring components are "tied" to the Spring container. That is just plain disingenious.
    EJB3 components are compiled with EJB-dependent annotations in their class files, so they are obviously tied to EJB as such. This is the nature of JSR-175 annotations, which is clearly your recommended model for developing EJB3 components. And for applying transaction and persistence services, you need to run in an EJB container, enforcing JNDI/JTA and its own class loader.

    Spring-style lightweight components on the other hand are plain POJOs that can be run nicely without any container jars. Configuration can simply be externalized via a Spring application context - if you want to. Transaction and persistence services are available in any environment, be it with JNDI/JTA or a with a local DataSource and native transactions, without extra class loader.
    If you have any questions about this issue, you know my email address, feel free to email me. I am quite happy to explain the intent of the spec in this area.
    As I indicated above, I did so a while ago to both Christian and you but never got any reply. I understand that it is quite hard for you to paint a coherent picture anyway, as there is no full EJB3 API specification or implementation yet. Some implications are already obvious, but assuming a widespread chance for standalone EJB3 containers is pure speculation at this point of time.

    How usable EJB3 will be in practice - not only from an EJB component implementation point of view (which all your examples refer to), but also from a deployment and client point of view - will only show once final implementations are available. Whether standalone EJB3 containers will work as straightforward as you want to make us believe remains to be proven too.

    As you know, Spring is dedicated to supporting all sorts of environments as first-class targets. And of course, it has already proven that its model works as advertised in all those environments - even with a variety of data access and remoting strategies. All of this is available right now, even including an early option to drive configuration via metadata attributes.

    It's also about choice: Hibernate, JDO, iBATIS SQL Maps, the OJB PersistenceBroker, and convenient JDBC are all viable data access choices that have their merits, so they all have first-class support in Spring. Spring provides a uniform transaction and DAO model for all of those, allowing to run corresponding DAOs in any environment without special effort.
    It would be truly great to see you guys get behind the spec, or even involved in it.
    As I already told you last time you and Christian expressed that invitation to me, I feel honored that you consider my views worth of being respected in the EJB expert group. However, the focus of the EJB spec is quite different from Spring's mission: Both are about component models, but Spring focuses much more on deployment flexibility and choice of data access and remoting strategies.

    Effectively, Spring could never be EJB3-compliant in the first place, because of the EJB2 compatibility issue and the requirement to provide both the component container and the O/R mapping service under a single umbrella. The added value for Spring users is questionable anyway: Why enforce a separate deployment unit and class loader when everything works smoothly without those?

    I personally favor a simple core container that does not affect the class loader and does not require a special deployment unit. It should work in any kind of environment, among those any J2EE server product. Specifically, that model should allow for pluggable transaction and data access strategies; same for other areas like remoting. Essentially: the Spring model.

    One of my biggest issues with EJB3 is still the combination of component model, remoting, and O/R mapping in one single spec, to be implemented and certified as a whole. This does not allow specialized vendors to provide certified products for a specific area. I strongly believe that those areas are separate concerns, and I'd like to see separate products concentrate on those areas.

    Juergen
  62. "tied"[ Go to top ]

    Of course, standalone EJB3-like containers may provide some additional API for (non-JTA) local transactions etc, but just in a proprietary fashion that is far from seamless.
    I don't know about that. Would it be really so hard to write a JTA mock implementation that would use local transactions? Basically, it would do nothing most of the time :-)
    EJB3 components are compiled with EJB-dependent annotations in their class files, so they are obviously tied to EJB as such.
    Correct, but these annotations will be available in j2ee.jar, which can be downloaded for free from Sun's web site. If you are developing a J2EE application, surely that's not too much to ask, is it?
    Effectively, Spring could never be EJB3-compliant in the first place, because of the EJB2 compatibility issue and the requirement to provide both the component container and the O/R mapping service under a single umbrella.
    You are not JDO-compliant either, yet you provide a reasonable JDO integration to make JDO developers' lives easier. Why not do the same thing for EJB3?
    As I already told you last time you and Christian expressed that invitation to me, I feel honored that you consider my views worth of being respected in the EJB expert group. However, the focus of the EJB spec is quite different from Spring's mission
    There is more to life than just Spring :-)

    Seriously, I understand that Spring is your focus right now but I think it's pretty obvious that both Spring and EJB3 will become major players in the Java world in the next few years, so I really don't understand all the hostility coming from the Spring team. Seriously, I am baffled.

    I see two great pieces of technology that can complement each other quite nicely, so why all the drama? Not only should we strive to make them easy to use with each other, but on top of that, I believe it would be *trivial* to do so.

    --
    Cedric
    http://beust.com/weblog
  63. "tied"[ Go to top ]

    If you write a Spring XML configuration file to configure your beans and you want to run your application outside of Spring, you will still need some Spring-compatible runtime. Same with EJB3.-- Cedric
    Correct, if you want to have declarative transactions or other Spring container services. The required Spring runtime is much slimmer than any EJB runtime could ever be, though, partly because it concentrates on one single, simple component model for use within an existing deployment unit (i.e. without extra deployment unit and without extra class loader).

    Spring is very driven by actual user requirements: There are a lot of people who are using it in standalone scenarios, often reusing business logic both there and in a server-side version of an application. This is one reason why our generic transaction and resource management is so popular: The same model can be used in both those environments, including declarative transactions.
    Would it be really so hard to write a JTA mock implementation that would use local transactions?
    Well, if you concentrate on local transactions. However, it still won't be that trivial: For example, you need to wrap the involved DataSource to correctly handle transactional Connections. You'd also need to handle the persistence context of the EJB3 EntityManager, i.e. the equivalent of a thread-bound Hibernate Session. The latter is probably the hardest part.

    What I have argued above is that making the EJB3 EntityManager work in a non-J2EE environment is not natural or seamless, because it has not been designed for this. In contrast, Spring can naturally adapt to such environments because this was a design goal right from the start. Furthermore, such standalone EJB3 EntityManagers won't be certified, losing part of the promise of a standard.

    This is not about good or bad: It's just a different tradeoff because of different design decisions. I perfectly respect that EJB has a server-side focus; this is also the public opinion of its purpose. However, Gavin's current public statements are confusing in that respect: He implies that EJB3 aims to provide a generic component model that is a full alternative to Spring's.
    Correct, but these annotations will be available in j2ee.jar, which can be downloaded for free from Sun's web site. If you are developing a J2EE application, surely that's not too much to ask, is it?
    Right - if you're developing a J2EE application. If you're developing reusable business components for multiple environments (J2EE and non-J2EE), it might seem inappropriate to build against the EJB jar. Admittedly, this also affects any other usage of JSR-175 attributes: It's an implication of that annotation mechanism rather than a peculiarity of EJB3 itself - a different topic.
    You are not JDO-compliant either, yet you provide a reasonable JDO integration to make JDO developers' lives easier. Why not do the same thing for EJB3?
    Seconding Rod: We will provide that level of support, as soon as EJB3 is available. We already do this for EJB2, as you might have noticed. In the case of EJB3, we can actually provide 2 different things: easy access to EJB3 Session Beans from a Spring context, and the EJB3 EntityManager as a further data access strategy (alongside the others that Spring supports out-of-the-box).

    The discussion above is not about that sort of integration, though. I might have misunderstood some points (sorry if I did), but there were direct comparisons between Spring and EJB3 as generic component containers. I also remember some earlier suggestions that Spring could become "EJB3-compliant": We seem to agree that this is not possible - and not a goal in the first place.
    There is more to life than just Spring :-)
    Very true! Actually, I've already spent too many hours of this beautiful Sunday preparing TSS posts ;-)
    Seriously, I understand that Spring is your focus right now but I think it's pretty obvious that both Spring and EJB3 will become major players in the Java world in the next few years, so I really don't understand all the hostility coming from the Spring team. Seriously, I am baffled.
    I very much welcome your cooperative tone in this posting - really, it's much appreciated!

    I don't see much hostility coming from the Spring team, though: I rather see a lot of reaction to the initial hostility coming from the EJB3 expert group against Spring. Some public statements were degrading Spring to just another IoC implementation, to be superseded by EJB3 (at least, implying this); this is clearly negating the full power of Spring's design and its services.
    I see two great pieces of technology that can complement each other quite nicely, so why all the drama? Not only should we strive to make them easy to use with each other, but on top of that, I believe it would be *trivial* to do so.
    Now it's me who's baffled :-) This could have been right from my own mouth: Spring and EJB3 complement each other more than they compete with each other. There is definitely some overlap, but there's also a lot of potential for synergy (in a J2EE environment). Actually, I've been taking this position right since the first discussions after Las Vegas.

    As I said, Spring will provide support for accessing EJB3 Session Beans and possibly also the EJB3 EntityManager as data access strategy. It's up to the application developer when to choose this combination: For dedicated J2EE applications, it is a viable strategy. For other scenarios, Spring with a different transaction and data access strategy might be more appropriate.

    Again, thanks for your down-to-earth points in this posting! I hope we can stop discussing Spring and EJB3 as directly competing alternatives now.

    Juergen
  64. "tied"[ Go to top ]

    Look, Gavin, while you personally may see EJB3 as a generic component model for any Java environment, this is clearly not an obvious intent of the EJB spec. EJB is part of J2EE, for usage within a J2EE server. You may be the most active EJB3 representative in the community, but that does not make your personal opinion the official position of the EJB expert group or of all J2EE vendors.
    Surely not.

    However, it seems you are being a bit unperceptive here. All it takes is *one* lightweight implementation of EJB3 to make my words come true. And you already know I am going to be involved in implementing the JBoss EJB3 container. Connect the dots....
    In particular, the only thing that will ever be J2EE-certified, is a full-blown EJB container shipped as part of a full J2EE server
    Since when was Spring an application server?? Why would it need to be J2EE certified??

    Now, I am not the legal expert here. However, I see no reason on earth why you can't implement EJB3 without having a full J2EE stack. You can provide a standalone JMS implementation, right? There are tons of them. I mean, I work for a company that's been providing a wole -application server- without being J2EE certified (as of this week we are now certified, of course).
    A colocated web tier is fine for EJB3 - as long as a colocated EJB container is available. For the others, you need a standalone EJB3 container that you deploy your components to - as an EJB jar. You need to start up that container, so that you can fetch your component proxies from it.
    s/EJB/Spring

    Hum, that whole sentence is just as true.
    Within that EJB3 container, your EJBs will run in a separate class loader, just like with EJB2.
    Now you lost me. Or, hum, maybe this is the crux of the matter. Is this whole debate really an argument over *classloaders*??
    The other option is to create your EJB3 components as plain POJOs. You cannot apply transaction or persistence services then, though - your components need to be deployed to an EJB container to make those work. That usage style is neither suitable for integration tests nor for usage in standalone applications.
    s/EJB/Spring
    I fully expect that there will be several "lightweight" EJB3 containers that may be embedded in Java applications, outside of an application server.
    While this may happen in some fashion, I would be very surprised if this were covered by the EJB spec itself.


    It doesn't need to be explicitly covered by the spec to be possible. All that is required is initiative on the part of implementors.
    In particular, the EJB3 EntityManager does not provide means for local transactions but rather depends on a JTA environment
    Now this is just silly. JTA is a trivial API that I can implement in five minutes. You are being disingenious again.
    EJB3 components are compiled with EJB-dependent annotations in their class files, so they are obviously tied to EJB as such.Spring-style lightweight components on the other hand are plain POJOs that can be run nicely without any container jars.
    Oh gawd, how many times do we have to say: EJB3 will support XML deployment descriptors. We just don't think people will choose to use them much. It will be quite easy to write EJB3 components without the completely harmless dependency to the annotations jar. And I am quite certain that spring will start to support annotations once JDK1.5 becomes entrenched. This is a silly objection.

    Juergen, I really don't want to get into some kind of acrimony with you guys, I'll just kinda echo Cedric in saying that I'm surprised and very disappointed to see your approach to this. I had not expected it. What I initially liked about Spring was the very pragmatic approach you guys took of being happy to integrate anywhere, with anything, and be a kind of "glue" framework to round off the rough edges of J2EE. Very much like the approach we took with Hibernate. We didn't set out to replace J2EE, just to fix what was broken. It seems to me like you could easily continue to provide a great value-added framework to EJB3 (eg, to integrate in other persistence solutions). I'm certain EJB3 will still contain some rough edges. And I'm trying hard to make sure that you guys and others get the hooks you need to be able to extend/improve the services provided by EJB3. But it looks like you've already decided not to go down that path, and it also looks like you've exchanged pragmatism for ideology. I might be wrong. I certainly hope so. :-(
  65. "tied"[ Go to top ]

    I do not think it is possible to implement JTA in five minutes, you need to implement XA specification to implement JTA.
  66. jta[ Go to top ]

    I do not think it is possible to implement JTA in five minutes, you need to implement XA specification to implement JTA.
    Not if all you want it for is to control local transactions, which is what Juergen is talking about. I mean what Cedric is calling a "mock" JTA.
  67. jta[ Go to top ]

    Yes, it is very trivial to implement "mock" JTA, it has meaning for tests.

    BTW I do not think application framework needs to demarcate transactions, transaction demarcation on server is not a good idea. In the ideal word user must transactions, not application or framework, in our word HTTP demarcates transaction, I think transaction demarcation framework is useless.
  68. Integration[ Go to top ]

    Gavin
    And I'm trying hard to make sure that you guys and others get the hooks you need to be able to extend/improve the services provided by EJB3. But it looks like you've already decided not to go down that path, and it also looks like you've exchanged pragmatism for ideology. I might be wrong. I certainly hope so.
    I'm a bit distracted by a new baby to get involved in this thread. TSS is lots of fun, but it can't really compete :-)

    However, I do want to clarify one thing: Spring absolutely will provide support for EJB3 where we feel that it's beneficial for EJB3 users. (Hopefully our existing EJB support will go part of the way.) Your speculation that we've "already decided not to go down that path" is wrong. I (and no doubt other Spring developers) will continue to express our own opinions on EJB3 (which of course might change if the draft spec changes significantly), but Spring will always continue to cater for the needs of its users. No doubt some of those users will work with EJB3.

    As Cedric points out, EJB (whatever version) and Spring will need to coexist and integrate. Though they compete to some extent, they are very different animals. Having them work together effectively will clearly benefit users.

    Rgds
    Rod
  69. Integration[ Go to top ]

    Gavin
    And I'm trying hard to make sure that you guys and others get the hooks you need to be able to extend/improve the services provided by EJB3. But it looks like you've already decided not to go down that path, and it also looks like you've exchanged pragmatism for ideology. I might be wrong. I certainly hope so.
    I'm a bit distracted by a new baby to get involved in this thread. TSS is lots of fun, but it can't really compete :-)
    Indeed? Congratulations! I've got a 9 month daughter so I understand. Isn't it amazing how you want to inject(via Spring, no doubt) you child into every conversation?

    Class SomeTopic extends SomeOtherTopic implements Topic
    {
       void setChild(Child yourChild)
       {
          this.child = yourChild;
       }

    }

    I guess when one of the PicoContainer guys procreates it'll be

    Class SomeTopic extends SomeOtherTopic implements Topic
    {
       void SomeTopic(Child yourChild)
       {
          this.child = yourChild;
       }

    }

    Just get that Spring 1.1 out before the lack of sleep really hits! :-)
  70. Integration[ Go to top ]

    Indeed? Congratulations! I've got a 9 month daughter so I understand. Isn't it amazing how you want to inject(via Spring, no doubt) you child into every conversation?
    Speaking of which, I have always wondered in what category making babies falls: setter injection or constructor injection? :-)

    --
    Cedric
    http://beust.com/weblog
  71. That's an ender[ Go to top ]

    Speaking of which, I have always wondered in what category making babies falls: setter injection or constructor injection?
    Is this the cue to end this thread?

    Ryan
  72. "tied"[ Go to top ]

    All it takes is *one* lightweight implementation of EJB3 to make my words come true. And you already know I am going to be involved in implementing the JBoss EJB3 container. Connect the dots....
    Sure. But that still doesn't make a standalone version of the JBoss EJB3 container officially certified or easy to use for the needs of a non-J2EE application. A proof of concept for EJB3 outside of a J2EE server is not enough: Consider that JDO implementations are fully designed - and can be certified - for such environments right from the start.
    Since when was Spring an application server?? Why would it need to be J2EE certified??Now, I am not the legal expert here. However, I see no reason on earth why you can't implement EJB3 without having a full J2EE stack. You can provide a standalone JMS implementation, right? There are tons of them.
    Well, some people were suggesting that Spring should become "EJB3-compliant", whatever that's supposed to mean: possibly, making its component model compatible with EJB3's. As I already said in my response to Cedric, we all seem to agree that this is not the goal. I repeatedly stated myself that Spring is an application framework, not an application server.

    Note that JMS allows for individual certification. A partly implementation of EJB3 cannot be certified, so there is a significant difference. A standalone EJB3 EntityManager might do its work correctly, but the EJB certification just covers usage within a J2EE environment. As I said, this is a significant difference to a dedicated persistence spec like JDO.
    Now you lost me. Or, hum, maybe this is the crux of the matter. Is this whole debate really an argument over *classloaders*??
    EJBs running in a separate class loader is an important difference to Spring components running in an existing class loader, for example in a web app's. "Class loader hell" is not accidentally a well-known term in the J2EE world: Simple class loader structure means less deployment headaches. A WAR file which uses Spring internally behaves just like any other WAR file.
    It doesn't need to be explicitly covered by the spec to be possible. All that is required is initiative on the part of implementors.
    Well, but that is then outside of the spec and thus not covered by certification - losing part of the promise of a standard. Note that all I initially argued was that such usage is not the intent of the EJB spec: You seem to silently agree now, in contrast to your initial reaction. We possibly just misunderstood each other...
    Now this is just silly. JTA is a trivial API that I can implement in five minutes. You are being disingenious again.
    See my earlier response to Cedric. It's not that simple: You need to worry about transactional DataSources and managing transaction-scoped persistence contexts. As experiences with custom ThreadLocal Sessions in Hibernate show, this is not as trivial as it seems at first glance. Do you really suggest to implement such crucial stuff in an ad-hoc fashion?

    As a side note: In general, I feel knee-jerk reactions when someone uses the word "silly" in conjunction with a carefully thought-out argument of mine. I really respect your work and your competence in the persistence and transaction area, so I assume you have just not fully considered the implications of local transaction management for a standalone EJB3 EntityManager.
    And I am quite certain that spring will start to support annotations once JDK1.5 becomes entrenched. This is a silly objection.
    As I said in my response to Cedric, this is an issue with JSR-175 attributes rather than EJB3 itself. It might not be that important, but it does have implications and is worth noting. Actually, it has been noted repeatedly before by other people. Also note that I didn't mean it as objection, rather as simply stating a fact. So I believe it doesn't qualify as "silly" either.
    What I initially liked about Spring was the very pragmatic approach you guys took of being happy to integrate anywhere, with anything, and be a kind of "glue" framework to round off the rough edges of J2EE. Very much like the approach we took with Hibernate. We didn't set out to replace J2EE, just to fix what was broken.
    We still adhere to our initial mission, and we certainly don't intend to replace J2EE. (Why do those "replacing J2EE" implications still pop up, anyway?) The difference is that Hibernate "just" addresses O/R mapping, while Spring addresses the whole area of application architecture. As you're well aware, they provide a nice combination and will continue to do so.
    It seems to me like you could easily continue to provide a great value-added framework to EJB3 (eg, to integrate in other persistence solutions). I'm certain EJB3 will still contain some rough edges.
    Again, see my previous post to Cedric. Spring will do its best to provide support for EJB3 just like it does for accessing EJB2 Session Beans and using Hibernate or JDO as data access strategy today. Integrating EJB3 into a Spring context will be seamless. There is more synergy than competition here, so please let's deemphasize these Spring *vs* EJB3 discussions.

    Also, let's clarify that Spring's component model should not become EJB3-compliant as such. While something like this could be achieved in a prototypical fashion quite easily, there is not much point in doing this in a full-fledged fashion, from my point of view: If you want to work with EJB3 for some parts of your application, use a proper EJB3 container for those.
    And I'm trying hard to make sure that you guys and others get the hooks you need to be able to extend/improve the services provided by EJB3. But it looks like you've already decided not to go down that path, and it also looks like you've exchanged pragmatism for ideology. I might be wrong. I certainly hope so. :-(
    All I'm personally arguing for is that there is no point in making Spring's component model EJB3-compliant as such. Integration of EJB3 into a Spring context is a completely different matter, and I already repeat myself in saying that this will be seamless. So please let's not confuse issues here: You are right in hoping that you're wrong :-)

    I certainly appreciate your effort to provide hooks in EJB3 for integration purposes. There shouldn't be too much need anyway: EJB3 Stateless Session Beans can be located via JNDI (with Spring's existing JndiObjectFactoryBean); the EJB3 EntityManager can be fetched from JNDI too, with JTA as transaction strategy. So such a combination should work seamlessly - in a J2EE environment.

    Juergen
  73. "tied"[ Go to top ]

    Sure. But that still doesn't make a standalone version of the JBoss EJB3 container officially certified or easy to use for the needs of a non-J2EE application. A proof of concept for EJB3 outside of a J2EE server is not enough: Consider that JDO implementations are fully designed - and can be certified - for such environments right from the start.
    Um. Well, I don't intend to get in arguments about such nontechnical things because, to be honest, I don't really care about stickers saying "blah blah compliant". Note that we both work on very successful infrastructure projects, neither of which are certified to comply with any spec.

    Actually I'm a bit confused about what exactly your stance here *is*, actually. On the one hand, you seem to be arguing that JDO is great because implementors can get certified. But you yourself don't seem to think it is important that spring is not certified.
    A standalone EJB3 EntityManager might do its work correctly, but the EJB certification just covers usage within a J2EE environment. As I said, this is a significant difference to a dedicated persistence spec like JDO.
    So hold on: code that uses the EJB3 EntityManager outside the container might be ever so slightly non-portable (it will be trivial work to port but whatever). On the other hand, we should all write Spring-specific code which is portable to what exactly?
    EJBs running in a separate class loader is an important difference to Spring components running in an existing class loader, for example in a web app's. "Class loader hell" is not accidentally a well-known term in the J2EE world: Simple class loader structure means less deployment headaches.
    Oh, certainly, I agree. ClassLoaders are a nightmare in J2EE. Would be nice to simplify that stuff too.
    Well, but that is then outside of the spec and thus not covered by certification - losing part of the promise of a standard.


    But I don't lose the promise of a standard by using Spring??? Juergen, I'm really confused.
    See my earlier response to Cedric. It's not that simple: You need to worry about transactional DataSources and managing transaction-scoped persistence contexts. As experiences with custom ThreadLocal Sessions in Hibernate show, this is not as trivial as it seems at first glance. Do you really suggest to implement such crucial stuff in an ad-hoc fashion?
    Juergen, this stuff is just Not Very Hard, and is certainly an incredibly well-understood problem. Both JBoss and Spring already had this functionality for years, so we both know what is involved. The problem with "custom ThreadLocal Session" is due to them being, well, "custom". If I implement that stuff myself, our users will have no problem with it.
  74. "tied"[ Go to top ]

    Note that we both work on very successful infrastructure projects, neither of which are certified to comply with any spec. Actually I'm a bit confused about what exactly your stance here *is*, actually. On the one hand, you seem to be arguing that JDO is great because implementors can get certified. But you yourself don't seem to think it is important that spring is not certified.
    I'm not arguing that standardization is important in all areas. IMO, there is an argument that middle tier glue frameworks and web frameworks should in general not be standardized, because they need to be able to adapt to personal preferences and evolve much quicker than a standard ever could. Users are often better served through "proprietary" open source products here.

    O/R mapping is a somewhat different beast. While there are certainly multiple valid approaches in that area, people seem to be very keen on standardization. And I strongly believe that if a standard, then there should just be a single one: Alternative solutions can still be built in a proprietary fashion. This is where the double JDO and EJB3 EntityManager efforts feel odd - different topic.

    Your position is not clear to me either: You believe that it is very important to standardize a Hibernate-like approach as EJB3 EntityManager, else you wouldn't spend so much time on it. On the other hand, you don't care much about standards. In particular, you don't care whether quite a bit of proprietary setup stuff is needed for standalone usage of an EJB3 EntityManager.

    Essentially, I wonder how much value standalone usage of an EJB3 EntityManager adds over Hibernate. Hibernate is designed for being used in all sorts of environments: It explicitly allows for local transactions, and provides well-defined configuration and resource management for local usage. The same applies to JDO: It's been explicitly designed for such usage too.
    So hold on: code that uses the EJB3 EntityManager outside the container might be ever so slightly non-portable (it will be trivial work to port but whatever). On the other hand, we should all write Spring-specific code which is portable to what exactly?
    Well, why should I choose the EJB3 EntityManager for a non-J2EE scenario when its usage will be somewhat non-portable anyway? In particular, why would I choose it over plain Hibernate? The latter will be a typical question, even if the JBoss EntityManager is built on Hibernate. What's your personal view on this? I get the impression that you won't promote Hibernate itself anymore.

    So it's not about the need for portability in all places. It's rather about why choosing a standard - i.e. the EJB3 EntityManager - for a scenario that it hasn't been explicitly made for, when there are powerful proprietary alternatives with similar model - i.e. Hibernate. In particular, when there's also a standard approach that explicitly covers such scenarios, i.e. JDO.
    Well, but that is then outside of the spec and thus not covered by certification - losing part of the promise of a standard.
    But I don't lose the promise of a standard by using Spring??? Juergen, I'm really confused.
    Spring does not promise to stick to a JCP standard in the first place, neither does Hibernate - but the EJB3 EntityManager does. Essentially, my feeling is that standalone usage of an EntityManager is not really standardized: In that case, I prefer a proprietary solution like Hibernate - or a standard like JDO - which has been explicitly designed for such a scenario.
    Juergen, this stuff is just Not Very Hard, and is certainly an incredibly well-understood problem. Both JBoss and Spring already had this functionality for years, so we both know what is involved. The problem with "custom ThreadLocal Session" is due to them being, well, "custom". If I implement that stuff myself, our users will have no problem with it.
    I'm just arguing that it is not something that the average user should need to code in an ad-hoc fashion. It needs to be shipped with the standalone EJB3 EntityManager: In particular, an EntityManager implementation needs to have been internally prepared for standalone usage (-> persistence context). I respect your coding ability, but this is quite far from a 5 minutes effort.

    Actually, Spring could provide added value here for standalone usage of an EJB3 EntityManager: Spring-based configuration is easily able to isolate proprietary setup of an EntityManager instance, passing it do DAOs via DI. Spring is also able to provide declarative transactions with any JTA-compatible backend, for example a local UserTransaction instance rather than one from JNDI...

    As a side note, where did JBoss have support for ThreadLocal Sessions for years? I'm not aware of this outside of an EJB3 context, which is fairly recent. Do you refer to the persistence context management of JBoss CMP here? At this point of time, the only production-ready pre-built solution for ThreadLocal Session management that I'm aware of is still Spring itself.

    Finally, we've just been talking about standalone usage of the EJB3 EntityManager, which is essentially a Hibernate-style library, except for the transaction issue. As far as I understand, this will be the only part of EJB3 which JBoss intends to support in a standalone fashion, outside of the J2EE server? Why oh why can't this be a separate O/R mapping spec, a la JMS...

    Juergen
  75. "tied"[ Go to top ]

    As I remember JBoss code, this stuff was implemented in 2.4. This design idea was used with DCOM many years ago, it was used by hibernate users before spring too. This stuff is very good, but it is trivial. There are more important problems too solve.
  76. "tied"[ Go to top ]

    As I remember JBoss code, this stuff was implemented in 2.4. This design idea was used with DCOM many years ago, it was used by hibernate users before spring too. This stuff is very good, but it is trivial. There are more important problems too solve.
    OK, so this was not referring to Hibernate Sessions in particular but rather to transaction-scoped resources in general. Such a thing has of course been done before. I was specifically referring to ThreadLocal management of transaction-scoped Hibernate Sessions, which I'm not aware of being provided in a pre-built fashion by JBoss at this point of time.

    Or was Gavin referring to Hibernate's JCA Connector here? Ah, that was possibly the case! There is indeed something similar to a ThreadLocal Session there through transactional JCA resources. Are you *guaranteed* to receive the same Session reference through a transaction there? Anyway, if that was what you meant, Gavin, then it's clear to me now.

    Note that I'm not talking about custom ad-hoc code by users but just about *pre-built* solutions. I know that you prefer your own code or forked library code here, Juozas, but many people prefer to reuse existing solutions as-is :-)

    Juergen
  77. "tied"[ Go to top ]

    This design is dictated by the real word, it is dictated by XA too. All resourcesw must be thread local or you need to implement concurency control in application yourself. I am sure this is only right architecture at this time, probly we will have something more scalable in the future, but this kind of servers, I/O are experimental at this time (custom sheduling).
  78. "tied"[ Go to top ]

    IoC and transaction mapping to thread is too trivial and I am trieng to provoke dicussion about AOP stuff :)
    I will contribute for spring myself if it will start to build data access aspect implementations. My personal preference is declarative data access and I am going to reimplement voruta for jdk 1.5 and to build it on top of AOP framework.
    I do not think plain AOP is usefull in application, but it is a very good way to implement framework itself and probably to let user customize it with AOP if he wants. It is very experimental idea, but I am sure it will work. This "hard to sell" idea is trivial too, but I think it is more serious.
  79. .. if I write a component that is ultimately destined to be running within a container, why I would test it outside the container?
    Mostly people are inslined to write components that may run within a container, but also should be usable outside - "component reuse", you know ;-) Hence the desire not to be tied to any container, yet to be able to use in with one.
  80. IoC + AOP[ Go to top ]

    The main focus of my comments was that JDK 5.0 annotations and, to a lesser extent, AOP, will have much much much much more effect on simplifying programming in Java than any of the current IoC frameworks can even hope to.
    A little more research would help here. Spring (a "current IoC framework" among many other things) already supports annotations for transaction management. The problem is that J2SE 5.0 isn't released yet, and so annotation support is irrelevant in the real world, and will be for a long time. We will release the trivial code we need to add for 1.5 annotation support, along with examples and documentation, before J2SE 1.5 reaches GA.

    In any case, annotations aren't always the key to simplification. (Just as well, as we need simplification now.) As I argue in J2EE without EJB, IoC + AOP is a match made in heaven. Annotations are a nice optional extra in some cases, such as transaction management.
    Annotations and AOP bring so much power to framework and middleware developers than IoC ever will. Shit, combine the two (AOP + annotations) and you have something really powerful.
    No, you need both Dependency Injection and AOP to keep your framework concerns out of application code. That's why Spring combines IoC + AOP. It is really powerful. And this is presumably why EJB3 tries to do some basic Dependency Injection.
  81. I don't think the author mix aop and ioc.That aop is next era of program structure is impossible .
  82. monolythic configuration[ Go to top ]

    Personally, I don't like monolythic configuration files. They depend on everything. No pluggability. No hot replacement. No modularity.

    I prefer the J2EE configuration principle: The components state their demands, i.e. "I need a DataSource" and the deployer satisfies them. But that has to happen on a per-component-basis. I can deploy the DataSource first and then add / replace / remove components that make use of it, one by one.

    The problem of J2EE in this respect were the nasty JNDI lookups, the handling of naming exceptions and even worth: the dependent components weren't notified, when the datasource changed. You had to write error handling code, that handled the relookup.

    And exactly that is the main advantage of IoC. The container can replace my datasource reference.
  83. Still gas in the tank[ Go to top ]

    Let's make it clear...AOP is not a replacement for OOP, but rather a compliment to it. Not even the AOP zealots like myself say that AOP is going to replace OOP.
    AOP will not replace OOP, just as OOP did not replace procedural programming -- building blocks from procedural programming, such as using procedures as scoping containers for data, are quite common in java programs after all.

    OOP adds concepts to the ones used in the procedural programming paradigm and AOP adds concepts on top of OOP. Or, for that matter, directly on top of procedural programming without involving any OO concepts, right?

    Is the following true? The aspects addressed by AOP are pretty cross-cutting to OOP concepts or procedural concepts...

    best regards

    /Jens
  84. Still gas in the tank[ Go to top ]

    The aspects addressed by AOP are pretty cross-cutting to OOP concepts or procedural concepts...best regards/Jens
    Plain question, plain answer: "It depends". I very much like to think of Aspects as an extension of Objects rather than something complementary. I would like to see aspects used on aspects and aspects being derived from objects etc. That's what I'd call AOP not that poor "general intercept this and lets mess with the class hiearchy here"-kind-of-thing that is sold as AOP today.

    So aspects are in that sense not cross cutting. The actual cross cutting may be done by a new syntactical element, the pointcut.
  85. Still gas in the tank[ Go to top ]

    Exactly. Aspects must have a framework to attach themselves to. All examples I've seen so far entail aspects being applied to objects, not replacing the objects. No objects...no aspects.

    I would very much like Bruce to explain just how AOP is changing the "orientation" of programming. During the JavaOne talk the example was event/observer notification. Hardly revolutionary. It cleaned the code up a bit, however, the underlying OOP pattern remained intact. Early on OOP had very exciting examples and benefits. AOP has a neat sounding name...for what essentially is an event that tells us when we enter a method and when we leave a method. Big deal.

    Taylor
  86. IOC+DI+Hibernate[ Go to top ]

    You can actually see what Spring and Hibernate can do together. Simply look at the PetClinic sample application, versus the stand-alone samples that you see elsewhere.
    Spring example:

    public List getPetTypes() throws DataAccessException {
         return getHibernateTemplate().
                     find("from PetType type order by type.name");
    }


    Note what you don't see here:

    - You don't see any additional resource management clutter in the code base at all. The facade is simply the line of code that does the work. You don't have to manage your own resources. (DI + IOC)

    - You can add your transactions declaratively. (AOP)

    - You don't have to do exception mapping, and can check them at appropriate times. (unchecked exceptions)

    I mention Hibernate, but you can also use this style of development with other persistence frameworks as well, Kodo (my favorite), OJB, IBatis, even JDBC. We're just combining a few concepts. When you layer the concepts in this way, the impact is exponential.

    And that's the point. Simplicity and leverage. One line of effort gives you more lines of value. One line of effort, if it's simple, is easier to write, maintain, read, and understand.

    In fact, the Spring framework is all about leverage. The configuration, for the most part, melts into the background and away from your code, except when you're defining your architecture, or your persistence model. If you like annotations instead, fine...use XDoclet (and it would be easy to add DI through JSR 175 annotations in Spring.)

    As problems get more complex, it will be extremely important to establish some simpler usage models, just as we did when we removed go-to from the language and offered alternatives.

    In fact, that's as inevitable as rain: improving simplicity and improving leverage.
  87. IOC+DI+Hibernate[ Go to top ]

    As I understand, you are talking more about AOP than IoC, as I understand from discussions IoC is about injection only and discussions are about constructor or setter. I agree, there must be no exeption handling, transaction demarcation or "close" in data access method, but all AOP frameworks are about the same too.
    As I rememember IoC from Avalon, it was (or probably is) about contacts.
  88. My point is that none of this can be considered in isolation.
  89. My point is that none of this can be considered in isolation.
    Bruce, you must be joking... To answer, YES IoC can be considered apart from, let's say AOP. Do you REALLY need an exemple, or can you figure out for yourself ?

    But maybe your sentence is incomplete...