Article: ICEFaces and Spring 2.5 in Java EE

Discussions

News: Article: ICEFaces and Spring 2.5 in Java EE

  1. Article: ICEFaces and Spring 2.5 in Java EE (83 messages)

    "ICEFaces and Spring 2.5 in Java EE," by Henry Roswell, explains how to deploy ICEFaces in a Java EE environment, including the ability to push content to multiple sessions as data is updated – even if you’re using Spring to manage JSF backing data.
    ICEFaces is a JSF component library that adds a unique approach to AJAX: it renders a DOM (Document Object Model) on the serverside, and delivers changes to that DOM to a client via AJAX push. What this means is that data can be updated from one client, and the updates can be reflected almost immediately – with no client intervention – on other clients. The ICEFaces component suite is fairly complete, including updates to the "normal" JSF components to use AJAX and a few other capabilities. For example, the inputText component, which renders , is now aware of user roles, and can participate in partial submits (so that the server gets data as it's entered, rather than waiting until a full page submit is executed.) The component suite also adds styling, a menu bar, a connection status widget, effects (I.e., highlights, pulses, fades), a progress bar, a file upload widget, charts, and a capable set of panels. However, all this comes at a price: ICEFaces works with JSF 1.2, but its Java EE support is not complete. This tutorial shows how to deploy ICEFaces in a Java EE container, and how to retain the ease of development and deployment that EJB 3 gives you – even without EJB3.

    Threaded Messages (83)

  2. Bad link[ Go to top ]

    Hi, Thanks for the article ... but you gave a bas link. The correct one is ICEFaces and Spring 2.5 in Java EE Cheers,
  3. Although its not the context, Whats the purpose of deploying of Spring in Heavyweight Container? If one wants to take the mileage of Spring, He should go for Light-Weight Container like Tomcat. Its better people spend their valueable time in writing the deployment procedure for Tomcat rather than JEE Container. Either you need to use HeavyWeight Container with JEE technologies or move to LightWeight Container with Spring and Hibernate. Dont be in the middle.
  4. The purpose is to get all the services JEE servers offer out-of-the-box, e.g. JPA, transaction manager, messaging server, web container, JSF. Then there are nontechnical reasons like existence of company policies that force you to use JEE server.
  5. In this example the reason to use spring is to be able to inject the EJB into your code, which you can't do with Servlet Spec 2.4. Essentially it is a workaround for a shortcoming of IceFaces. If this is enough reason to introduce a Spring configuration is very debatable. Mix and match always sounds good, but it means increasing entropy and management overhead. At the end of the day you need to weigh your options and decide.
  6. Although its not the context, Whats the purpose of deploying of Spring in Heavyweight Container?

    If one wants to take the mileage of Spring, He should go for Light-Weight Container like Tomcat.
    Its better people spend their valueable time in writing the deployment procedure for Tomcat rather than JEE Container.

    Either you need to use HeavyWeight Container with JEE technologies or move to LightWeight Container with Spring and Hibernate.

    Dont be in the middle.
    This debate has been going on for several years now, and endless threads have touched and discussed the topic. However, I have yet to come across a conclusive list of reasons when it makes complete sense to use both technologies in an entirely complementary fashion. With the emergence of EJB3 and its simplified programming model (including Dependency Injection, Annotations, etc), it is becoming a lot less clear why one would use the two technologies together. I also believe the Heavyweight/Lightweight argument is loosing a lot of ground in this debate since most J2EE offerings can now be configured and run in "stripped down mode" with only those container services required by the application. So, without trying to hijack this thread, I would be keen to hear from people who have identified a need to combine the two technologies succesfully (J2EE/EJB3 and Spring 2.x), and the reasons why.
  7. I would be keen to hear from people who have identified a need to combine the two technologies succesfully (J2EE/EJB3 and Spring 2.x), and the reasons why.
    Combining these two technologies (Spring and JEE 5 / EJB 3) is a critically important business decision for consultancies because this is the most complex architecture available, and thus the most efficient way for gouging every last dime from customers ... Besides of that, i cannot think any pressing reasons :) /Henri Karapuu
  8. I would be keen to hear from people who have identified a need to combine the two technologies succesfully (J2EE/EJB3 and Spring 2.x), and the reasons why.


    Combining these two technologies (Spring and JEE 5 / EJB 3) is a critically important business decision for consultancies because this is the most complex architecture available, and thus the most efficient way for gouging every last dime from customers ...

    Besides of that, i cannot think any pressing reasons :)

    /Henri Karapuu
    I think you've hit it close enough to provoke a flood of responses from the consultants who frequent TSS :)
  9. I think you've hit it close enough to provoke a flood of responses from the consultants who frequent TSS :)
    I'm actually a consultant myself, and this was just some lighthearted self-irony for friday evening [while i was waiting for my new ridiculously expensive pearl white business cards with 'systems architect' text printed and embossed with elegant font]. Now. That was double self-irony. There are of course some pretty good consultants (like me :), but overall i think consultants and systems architects should be subject of more jokes than lawyers. /Henkka Karapuu
  10. Because you had to use EJBs. I worked on a project a few years ago that stated we *had* to use EJBs. No choice. And it *had* to run on Oracle9iAS. Again, no choice. This was pre-Spring, so I did my only DI, but injecting POJOs into Sessionbeans, so I followed the letter, if not the spirit of the law. With Spring, I would have dome something similar.
  11. I would be keen to hear from people who have identified a need to combine the two technologies succesfully (J2EE/EJB3 and Spring 2.x)
    I think the question is just "EJB3 and Spring 2.x". Those are really the competing technologies. Spring is very complementary towards the rest of JEE - which include JSF, and thus ICEFaces + Spring would be reasonable (assuming you prefer both of those to other options).
  12. Naveen
    Although its not the context, Whats the purpose of deploying of Spring in Heavyweight Container? If one wants to take the mileage of Spring, He should go for Light-Weight Container like Tomcat. Its better people spend their valueable time in writing the deployment procedure for Tomcat rather than JEE Container. Either you need to use HeavyWeight Container with JEE technologies or move to LightWeight Container with Spring and Hibernate.
    Some reasons: 1. Using Spring gives you the choice of "heavyweight" or "lightweight" container. Using EJB doesn't. Anyone planning to talk about how lightweight "embedded" EJB3 solutions are in Tomcat or the like, please first check how large and complex they are. Spring is far more portable than EJB. 2. Because Spring's component model is far more capable than EJB's in DI and AOP, a well as being more extensible and configurable. In Spring 2.5, it also implements the @Resource annotation and other Java EE 5.0 annotations as well as much much more. 3. Because Spring and EJB are not mutually exclusive. If the two of them together do things that neither does alone, that's fine. 4. Because adding Spring to an EJB environment, if you wish to do so, is simple. Rod, Founder, SpringSource
  13. What do you think of ICEFaces?[ Go to top ]

    I've been monitoring this thread for peoples experiences with ICEFaces. I was obliged to take a look at ICEFaces recently and i wasn't impressed. JSF is not my thing anyway, but AFAIK ICEFaces is a leading JSF implementation so I was at least expecting it to be stable. Even with my reservations about JSF, I was still surprised at how fragile and buggy ICEFaces appeared to be. Needless to say, we have avoided using it, but it could come back again (courtesy of our strategy team :^)). I'm interested in hearing from people with real production experience with ICEFaces. It was so bad I'm wondering if most of our difficulties came down to us not knowing how to get the best out of it (configuration, work-arounds etc)! In particular we experienced constant network chatter, connection timeouts, and constant javascript errors in the browser. Is this common? Thanks, Paul.
  14. Re: What do you think of ICEFaces?[ Go to top ]

    In particular we experienced constant network chatter, connection timeouts, and constant javascript errors in the browser. Is this common?
    It sounds like you ran into a few problems. The network chatter you're referring to is likely the ICEfaces connection heartbeat. The interval is adjustable, or, if you don't need to detect connection failure, you can turn it off. (The heartbeat allows a user depending on Ajax Push to know when you've rebooted the server.) A connection timeout is displayed when the server does not respond promptly. Again, the interval is configurable (did the connection time out repeatedly?). (The default values for these intervals could probably use some tuning for varied network conditions.) If you observed errors in the Firebug console, you may want to update to ICEfaces 1.7beta1 released today. http://blog.icefaces.org
  15. Re: What do you think of ICEFaces?[ Go to top ]

    AFAIK ICEFaces is a leading JSF implementation so I was at least expecting it to be stable.
    IceFaces is not actually a JSF implementation. It's a JSF add-on (ajax component library and then some more). Apache MyFaces and Sun's RI are the implementations. I was consulting/contracting JSF full time for about two years, and saw relatively little evidence of IceFaces being used in the field. Thinking seemed to be: "JSF is complex enough as it is so we don't want to add any extra stability-risking complexity on top". This is not at all isolated to IceFaces, which may well be the best of the bunch, but all JSF Ajax stuff seems to be retrofits on top of a framework that simply was not designed for Ajax. As of JSF itself; I'v moved to GWT about a year ago (and would NEVER move back to JSF), but to tell the truth JSF served me relatively well. Some architectural and design deficiencies are balanced by the wide industry adaptation. /Henri Karapuu
  16. Re: What do you think of ICEFaces?[ Go to top ]

    AFAIK ICEFaces is a leading JSF implementation so I was at least expecting it to be stable.


    IceFaces is not actually a JSF implementation. It's a JSF add-on (ajax component library and then some more). Apache MyFaces and Sun's RI are the implementations.

    I was consulting/contracting JSF full time for about two years, and saw relatively little evidence of IceFaces being used in the field. Thinking seemed to be: "JSF is complex enough as it is so we don't want to add any extra stability-risking complexity on top". This is not at all isolated to IceFaces, which may well be the best of the bunch, but all JSF Ajax stuff seems to be retrofits on top of a framework that simply was not designed for Ajax.

    As of JSF itself; I'v moved to GWT about a year ago (and would NEVER move back to JSF), but to tell the truth JSF served me relatively well. Some architectural and design deficiencies are balanced by the wide industry adaptation.

    /Henri Karapuu
    Thanks Henri, ICEFaces "Direct-to-DOM" based architecture is very complex. And I agree that there does seem to be tension between pure JSF (Sun RI) and ICEFaces. When we ran into trouble we tried implementing the same thing using the JSF RI which proved to be more stable (although we had issues here too). All of it (including the JSF spec) feels like work in progress. Which is a shame considering that JSF has been out for a number of years now. Unfortunately we may not be given the choice. ICEFaces wins hands down when it comes to their "feature list", and being "JEE standards compliant" which is what matters to our Strategy group :^). The fact that no one is using it (I haven't seen much evidence of actual usage) and it doesn't work very well doesn't matter to them. I am just a contractor/consultant, so I do not have much influence. Of course you and I are just two data points. Hopefully more people will chime in with their experiences. Paul.
  17. Re: What do you think of ICEFaces?[ Go to top ]

    I'm interested in hearing from people with real production experience with ICEFaces. It was so bad I'm wondering if most of our difficulties came down to us not knowing how to get the best out of it (configuration, work-arounds etc)
    We're using IceFaces in production, Our application was originally in pure JSF (no components add-on) then converted to use IceFaces components, and then from then on we used more and more IceFaces added features. Since we tackled the conversion slowly one step at a time we had a very sucessful results. We orignally even had home made ajax in our pure JSF application using home made servlets to communicate etc, It took us a week or two of developpement/debugging to have an autocomplete input text in our application, When we switched to IceFaces it only took us a day to implement the same thing, and we didn't have to bother coding Javascript Max
  18. Get over it already - when you want to use Spring; use it - hey I even do in some occasions.
  19. Why is it that every time JEE comes up - Spring fanatics go wild
    Check the title of this thread :-)
  20. Yep - It would have been better to place my comment in context. This thread immediately got hijacked by a fanatic stating:
    Although its not the context, Whats the purpose of deploying of Spring in Heavyweight Container?
    I mean this was not a thread on deployment, right? Well - somehow it became one.
  21. Re: Portability[ Go to top ]

    I honestly can't believe myself for wading in to another discussion on Spring/EJB, but this statement caught my eye (as I'm sure it caught the others who have worked for years on JEE): "Spring is far more portable than EJB." How on planet earth does a non-standard environment mean greater portability, and if you throw out the 'extensions' that app server vendors have placed on their platforms, my question is where do you deploy other than Tomcat and achieve portability? I apologize to Jan for continuing the so-called hijacking of another thread, as I think the original post was worthy in its own right not to digress in to a macho-match between supposedly pro-EJB v. anti-EJB crowd, but I'll take the bait: with JEE5 (can we agree that this is the discussion), u have Glassfish, WebLogic, Geronimo, WebSphere 6.x (Randy Schier has assured us of EJB3 support), and JBoss 4.2x (Burke has assured us of EJB3 support), u have a marketplace of solutions that abide by the new spec.... For years, it was fashionable to deride the so-called portability of EJB-based apps or components, and I will take part of the fall for advocating for a 3rd party off-the-shelf component offering, but why does that extend to the present? It just seems that the same base arguments are followed, regardless of the enhancements made to simplicity and portability in EJB3... There is greater portability in EJB3 than before, and Spring, if you follow v. 2.5, does the same, though I am still trying to work out a distribution model that does not involve integration via JAX-WS or ESBs on top of app servers, unless that vendor has specifically built their solution to run Spring a la WebLogic.... Is there not backward compatibility in JEE? Is there not a compliance process for portability with the AVK? Is there not a whole network of Java developers who understand what portability means to their opportunities and costs, just like Spring developers know there are more opportunities by closely maintaining adherence to that platform? It comes down to F.U.D., and the spreading of propaganda in order to try and bring down a franchise that made it all possible, with job numbers, fake competitive analysis, and vitriol of attacks, I hate to b a counter-weight in this argument, but it is getting obnoxious the extent to which even 'portability' is used in this discussion... Sitting on the JEE6 expert committee, and hating on EJB 3.1 is comical at best, and Sun, if it were not some altruistic developer love-in would boot u 4 making the accusations about the core JEE technology, so instead some of us will have to defend...its transparent to c that without the removal of EJB from JEE (which u apparently seek), SpringSource has a limited shelf-life on its own, sorry to be so confrontational, but it will reach an end, and the betting is still on JEE to prevail... (damn, I hate myself for this post)....
  22. Re: Portability[ Go to top ]

    Douglas I don't want to get into a flame war, especially in a thread that was nothing to do with this. So I'll just correct the more obvious fallacies.
    It comes down to F.U.D., and the spreading of propaganda in order to try and bring down a franchise that made it all possible, with job numbers, fake competitive analysis, and vitriol of attacks, I hate to b a counter-weight in this argument, but it is getting obnoxious the extent to which even 'portability' is used in this discussion...
    My "attacks" are hardly vitriolic. They are fact-based. I have justified my arguments with hundreds of pages and detailed examples. It is predictable, offensive (and "vitriolic") for you to assert that anything is "faked." Rgds Rod
  23. Re: Portability[ Go to top ]

    Douglas

    I don't want to get into a flame war, especially in a thread that was nothing to do with this.

    So I'll just correct the more obvious fallacies.
    It comes down to F.U.D., and the spreading of propaganda in order to try and bring down a franchise that made it all possible, with job numbers, fake competitive analysis, and vitriol of attacks, I hate to b a counter-weight in this argument, but it is getting obnoxious the extent to which even 'portability' is used in this discussion...

    My "attacks" are hardly vitriolic. They are fact-based. I have justified my arguments with hundreds of pages and detailed examples. It is predictable, offensive (and "vitriolic") for you to assert that anything is "faked."

    Rgds
    Rod
    Hi Rod, I have taken a look at your facts and the problem is that they are selective. Firstly why EJB versus Spring? They are completely different things. Why not compare EJB and OSGi as a skills requirement? That would be more like apples to apples instead of apples to pears. I'm not a defender of EJB, but so called facts like these are nothing more than marketing in my opinion. In most of your advocacy of Spring you could replace the word Spring with DI Framework and your facts would read the same. Branding a design pattern as though it is a product is misleading in my opinion and makes me question your motives. You simply aren't comparing apples with apples. Here are some alternative facts. 1. Dependency Injection is merely a design pattern that allows for the construction of objects in an OO fashion when using an early bound language like Java. You don't need Spring to do DI. 2. To assemble "components" or "modules" at deployment time, requires a means of packaging components separately at compile time, and some means of component/module discovery and binding at runtime. Both OSGi and EJB address this model of deployment, DI frameworks like Spring do not. The shared purpose of EJB and OSGi is described here:
    Why OSGi? OSGi is being adopted in an increasing number of projects. The spec provides a common model for writing and deploying apps to local or remote computers in modularized form. Instead of creating monolithic app, the OSGi spec allows the collaboration of many small components.
    Why not spend some time discussing these facts. Or are you only interested in facts that serve your purpose? Paul.
  24. Re: Portability[ Go to top ]

    Paul Spring is far more than DI. It is a wide-ranging framework--yes, a project/product that is far more than a single design pattern--that provides a capable, flexible component model. Personally, I don't think that EJB vs Spring is apples-to-apples either, but plenty of folk make the comparison (and often from the pro-EJB camp). As for OSGi--we are in agreement. It's a Good Thing and its time has come. In fact, SpringSource is playing a leading role in taking OSGi to the server-side. As witness the Spring Dynamic Modules for OSGi project, which combines the benefits of Spring with those of OSGi, and our active participation in the OSGi Alliance. I believe that OSGi is central to the future of enterprise Java, while EJB is not. Note that I have always distinguished EJB from Java EE. I believe that EJB is the bad apple in the Java EE barrel. Rgds Rod
  25. Spring and OSGi[ Go to top ]

    As for facts, the synergy between Spring and OSGi is not just my opinion. Take for example, the comment of Peter Kriens, Technical Director of the OSGi Alliance,that:
    [Spring and OSGi] is a marriage made in heaven, it is very complementary but together they form a much more powerful model.
    Rgds Rod
  26. Re: Portability[ Go to top ]

    I believe that OSGi is central to the future of enterprise Java, while EJB is not. Note that I have always distinguished EJB from Java EE. I believe that EJB is the bad apple in the Java EE barrel.
    Rod, This sounds like the "parable of the boiled frog" learning disability. I am sure this belief is central to your strategy. I do not think EJB is bad any more. You might want to check with others. mani
  27. Re: Portability[ Go to top ]

    Let me clarify the "apples-to-apples" part here. I don't believe that EJB/Spring is an apples to apples comparison because Spring's scope is much broader, it's much superior where overlap exists (DI, AOP, lifecycle) with the exception of some specialized remoting scenarios, it's more flexible and extensible, and it runs in and is suited to a much broader range of application architectures. Categorizing Spring (or EJB) as simply a DI container is simply wrong. Again, Java EE > EJB.
  28. Re: Portability[ Go to top ]

    Let me clarify the "apples-to-apples" part here. I don't believe that EJB/Spring is an apples to apples comparison because Spring's scope is much broader, it's much superior where overlap exists (DI, AOP, lifecycle) with the exception of some specialized remoting scenarios, it's more flexible and extensible, and it runs in and is suited to a much broader range of application architectures. Categorizing Spring (or EJB) as simply a DI container is simply wrong.

    Again, Java EE > EJB.
    Hi Rod, This is the problem. Beyond a branding exercise what is Spring exactly? You agree that it is not a component model. It is not OSGi although it wraps OSGi. It is not a bunch of JEE services although it wraps JEE services. It is not Hibernate although it wraps Hibernate, it is not AOP although it wraps... I could continue. A bunch of glue code built around a DI Framework. Useful but not revolutionary. All this stuff could be glued together with any other DI framework like Guice or even without a framework at all. You could choose to write your own DI framework in a weekend it is not that hard. Let me coin another phrase: Java > Spring. I think it is time to stop the FUD and the absurd marketing and get back to programming don't you? Paul.
  29. Re: Portability[ Go to top ]

    Let me clarify the "apples-to-apples" part here. I don't believe that EJB/Spring is an apples to apples comparison because Spring's scope is much broader, it's much superior where overlap exists (DI, AOP, lifecycle) with the exception of some specialized remoting scenarios, it's more flexible and extensible, and it runs in and is suited to a much broader range of application architectures. Categorizing Spring (or EJB) as simply a DI container is simply wrong.

    Again, Java EE > EJB.


    Hi Rod,

    This is the problem. Beyond a branding exercise what is Spring exactly? You agree that it is not a component model. It is not OSGi although it wraps OSGi. It is not a bunch of JEE services although it wraps JEE services. It is not Hibernate although it wraps Hibernate, it is not AOP although it wraps... I could continue.

    A bunch of glue code built around a DI Framework. Useful but not revolutionary.

    All this stuff could be glued together with any other DI framework like Guice or even without a framework at all. You could choose to write your own DI framework in a weekend it is not that hard.

    Let me coin another phrase:

    Java > Spring.

    I think it is time to stop the FUD and the absurd marketing and get back to programming don't you?

    Paul.
    You know what Paul, it may not be hard, but YOU DIDN'T DO IT. I love when guys talk about how easy or lame something is, but pretty much never fail to offer anything. It is jealously, nothing less. Whenever something gets too large, it becomes a threat to some, so they spend inordinate amounts of time trying to tear the thing down. If you have superior solutions, offer them up. The market saw Spring's solution and the market doesn't agree with you. If you have a better solution than Spring's DI, Spring configuration, Spring's AOP, Springs persistence support, put your better solution out here, so the rest of us can see it in the full light of day.
  30. Re: Portability[ Go to top ]

    A bunch of glue code built around a DI Framework. Useful but not revolutionary.
    All this stuff could be glued together with any other DI framework like Guice or even without a framework at all. You could choose to write your own DI framework in a weekend it is not that hard.
    Let me just do a quick subsitution on that statement, so I can get an analogy in: "All this database access could be done together with any other ORM framework like Castor or even without a framework at all. You could choose to write your own Database Access framework in a weekend it is not that hard." Hibernate has been a massively successful project, because it solved a particular set of problems well. Developers have voted with their feet and made it a de-facto standard. Since Hibernate these days is a superset of the EJB3 spec, it is arguably more important to be familiar with Hibernate than it is with straight EJB3 as it provides greater transferable skills. The fact is, for the past 3-4 years Spring has provided an approach to composing applications that has received so much mindshare as to make it another de-facto standard. It provides a ton of functionality over and above any DI framework you could write in a weekend and it is pure hyperbole to suggest otherwise. Developers are torn between what is new and interesting, and what is standard and dependable. We always like our new toys, but (perversely) we also long for a consistent approach. Those of us that have been using Spring for years are not about to drop it in favour of anything else simply because its shiny and new. Spring worked in the past, it works now, it looks like it will carry on adding value - so why would we care if it could be done with another framework? What value does that bring? Why on earth would you bother using anything else? Echoing your question, why not just get on and write code and stop worrying about it? Spring: it's a big set of libraries that a lot of people find useful. Get over it.
  31. Re: "De Facto Standard"[ Go to top ]

    Here-in lies the case: that Spring has achieved such market penetration that it should be considered on the same level as a real standard like EJB, and we are privileged to listen to job statistics that prove the supposed supremacy of the framework to the component model (apologies, Solomon, I do appreciate your efforts to describe the state of affairs)... We could go on and on about developer productivity and it would have seemed that this argument could have been put to rest with Rod on the JEE6 expert committee, though his personal vendetta against EJB 3.1 apparently prevents that, so I will talk about the business side of this discussion: Managers, Developers, and CxO's will make determinations based on a confluence of factors, including productivity, but also including adoption, support, ISVs, and many others...here is where SpringSource is doing a masterful marketing job (no sarcasm) portraying EJB as a dying albeit not-dead franchise...with support from the very platforms that they rely on for deployment, outside of the venerable Tomcat, EJB has an ongoing life-span... Making a business decision on development and deployment are inextricably linked, but not necessarily vital, if u believe the Spring model, for we are comparing nuances at this point on the development side (pardon me), and without a clear deployment platform to rest the model, the only option is ubiquity, this much we can all c... With EJB3x, an IT person can achieve the same thing that Spring offers without the risk, am I missing something? I again beg for forgiveness for being inflammatory, but when the attacks come, some perspective on the pro-EJB side is in order - - when u use an app server, you have the development and deployment built-in, when u use Spring as a development framework, u must also consider the deployment, which makes the recent Spring Source acquisition a good 1, but not pervasive, not even close... Until the JCP takes up Rod's cause of abandoning customers, abandoning legacy apps, abandoning innovation at the Java transactional component level, and ditches EJB, we r having a ridiculous convo....only then does Spring become what the respectable amount of proponents say it is: a de facto standard, and that day, has never been promised, may never come, and may not be welcome... until then, we all can continue to have these silly EJB is bad discussions....
  32. Getting the facts straight[ Go to top ]

    You know what Paul, it may not be hard, but YOU DIDN'T DO IT.
    Yes you are right. I didn't. An neither did Rod Johnson. The first Java DI framework I remember coming across was Pico Container. Some would argue that the DI pattern goes back way before then and would point to examples in Smalltalk in the mid 80's. You are also right. I couldn't build Spring in a weekend, but I could do some rudimentry DI, gluing together code written by others. My point is that you can use the DI pattern without a framework and it is not that hard to do. I think Spring is a fine DI framework. I have no problem with the code. What I have a problem with is the marketing, the branding (wrapping the work of others), false comparisons and the general mis-representation emanating from a Commercial company. I have made several points which you could choose to respond to or you could just call me names for not swallowing SpringSources's marketing spiel hook line and sinker. It is up to you. If you want to debate the technical issues, then why not start with this one:
    Most people who started out using EJB never needed it in the first place. People woke up to the idea that they didn't need distributed components to scale. They could get away with building single WAR monolithic applications, they didn't need the JEE component model. All they needed was JEE services
    Or this one:
    To assemble "components" or "modules" at deployment time, requires a means of packaging components separately at compile time, and some means of component/module discovery and binding at runtime. Both OSGi and EJB address this model of deployment, DI frameworks like Spring do not.
    Or this one:
    Dependency Injection is merely a design pattern that allows for the construction of objects in an OO fashion when using an early bound language like Java. You don't need Spring to do DI.
    Or this one:
    Beyond a branding exercise what is Spring exactly? You agree that it is not a component model. It is not OSGi although it wraps OSGi. It is not a bunch of JEE services although it wraps JEE services. It is not Hibernate although it wraps Hibernate, it is not AOP although it wraps... I could continue.
    Or this one:
    Java > Spring.
    Or you could just carry on calling me names. Paul.
  33. Re: Getting the facts straight[ Go to top ]

    The first Java DI framework I remember coming across was Pico Container.
    And? The first search engine I came across was Altavista. But guess what? Google did it better. No-one is claiming novelty is any kind of factor apart from you.
    My point is that you can use the DI pattern without a framework and it is not that hard to do.
    Funnily enough, so were thousands of other people, years and years ago. This is not new. I, along with many others, was more than willing to ditch my "not that hard, home grown solution" for something that did the same thing, better, with more features and a vibrant user community. I could write an FTP client. Or I could use commons-ftp. What is the difference? What exactly are you upset about?
    If you want to debate the technical issues, then why not start with this one:
    Frankly, I don't care for any of your "technical" objections - they're a mix of vague statements and incredulous denigration of what Spring does or does not do. At root, you seem to not like Spring, and will discourage anybody fomr using it (or indeed, believe those users are victims of some marketing blitz or other).
  34. Re: Getting the facts straight[ Go to top ]

    Frankly, I don't care for any of your "technical" objections - they're a mix of vague statements and incredulous denigration of what Spring does or does not do. At root, you seem to not like Spring, and will discourage anybody fomr using it (or indeed, believe those users are victims of some marketing blitz or other).
    Ok. Fine. P.
  35. Re: Getting the facts straight[ Go to top ]

    Thanks for the "lesson." Hey everyone, here is a newsflash Rod Johnson didn't invent DI. Paul, here is your problem. You imply that someone stated something, then you argue how they were wrong. No one, but you, even implied that Spring claimed to invent DI. Why don't you assume, for a moment, that programming knowledge doesn't begin and end with you? That somehow, you possess and insight that the rest of us lack. Frankly, it hard to take you seriously. You want have a problem with marketing that I think simply doesn't exists. I think your technical points are...empty because they originate from a fairly arrogant fallacy, namely, that those who use Spring did so not because they understand it, but because they were duped. And that somehow you know better. I have no problem debating the merits, but that has to be, IMO, an fundamental agreement on the premise. I just don't agree with yours. I just feel like I've seen your "type" before. Someone who doesn't like a particular thing, not because of any real technical reason, but because it is popular. Experience has shown me that I don't enjoy the debate and rarely learn anything. If were were talking about say, Hivemind vs. Spring, or Guice v. Spring or JSF v. GWT, truly on the merits, that would be something I could get into. But "comparisons and the general mis-representation emanating from a Commercial company?" Sorry. I don't think this has happened at all. All I've seen from the Spring guys is here is what we have and why we think it is useful. Use it or not.
  36. And now back to the original point[ Go to top ]

    I think your technical points are...empty because they originate from a fairly arrogant fallacy, namely, that those who use Spring did so not because they understand it, but because they were duped. And that somehow you know better.
    It may really be hard to stand Paul in discussions here. But back to the original question of the thread: *If* you do are thinking to use IceFaces in a basic JEE5 environment and you like the DI features of EJB3 - Is this reason enough to pull a framework like Spring (much of which is complimentary to standard ways of doing things in the JEE5 container) into your project. I'd say it's overkill, it's going to increase entropy that needs management and so on. You might think of turning your project in a Spring project of course (which needs some sort of migration plan, additional user training etc.) or you might think of creating a greenfield project based on an all out IoC/DI model based on Spring. Which is a different animal. Spring, IMO, is like a Swiss Army Knife, with more blades and tools that a usual JEE environment but with the additional requirement that for building the actual application you get more of a knife construction kit than a knife. This is like it used to be with british sports cars: Buying the car kit required you to buy the actual engine somewhere else, but was much cheaper and people quite often ended up with superior cars.... But car kits are not for everyone. Some people just like their Capri assembled and ready to go from the car dealer.
  37. Re: Getting the facts straight[ Go to top ]

    Oh, one more thing. I'm didn't call you a name, I called you out. Here is the post again "You know what Paul, it may not be hard, but YOU DIDN'T DO IT. I love when guys talk about how easy or lame something is, but pretty much never fail to offer anything. It is jealously, nothing less. Whenever something gets too large, it becomes a threat to some, so they spend inordinate amounts of time trying to tear the thing down. If you have superior solutions, offer them up. The market saw Spring's solution and the market doesn't agree with you. If you have a better solution than Spring's DI, Spring configuration, Spring's AOP, Springs persistence support, put your better solution out here, so the rest of us can see it in the full light of day. " No names. I don't necessarily agree with Bob Lee's reasoning WRT Spring, but know what he did? He put his money where is mouth is and released what he felt was a superior solution. No "Rod Johnson didn't event this" or "Spring marketing did that." He rolled up his sleeves and put something out there and now the market will decide who is better. Ditto with Rod Johnson. Even in his book, I don't recall seeing him bad mouth marketing or people. He stated this is what's wrong and here is what I believe to be right. The market reviewed his work and here we are.
  38. Re: Getting the facts straight[ Go to top ]

    Hi David, This is what Rod said
    Let me clarify the "apples-to-apples" part here. I don't believe that EJB/Spring is an apples to apples comparison because Spring's scope is much broader, it's much superior where overlap exists (DI, AOP, lifecycle) with the exception of some specialized remoting scenarios, it's more flexible and extensible, and it runs in and is suited to a much broader range of application architectures. Categorizing Spring (or EJB) as simply a DI container is simply wrong. Again, Java EE > EJB.
    I think this is meaningless marketing. You obviously disagree. Paul.
  39. Re: Getting the facts straight[ Go to top ]

    it's much superior where overlap exists (DI, AOP, lifecycle) with the exception of some specialized remoting scenarios, it's more flexible and extensible, and it runs in and is suited to a much broader range of application architectures. Categorizing Spring (or EJB) as simply a DI container is simply wrong.
    Sorry I did not see Rod's post. Otherwise, I would not have made a post about "Spring competing with EJB in core areas". Is it just Spring ABC or is it Spring marketing?
  40. Re: Getting the facts straight[ Go to top ]

    This is what Rod said


    Let me clarify the "apples-to-apples" part here. I don't believe that EJB/Spring is an apples to apples comparison because Spring's scope is much broader, it's much superior where overlap exists (DI, AOP, lifecycle) with the exception of some specialized remoting scenarios, it's more flexible and extensible, and it runs in and is suited to a much broader range of application architectures. Categorizing Spring (or EJB) as simply a DI container is simply wrong.

    Again, Java EE > EJB.


    I think this is meaningless marketing. You obviously disagree.

    Paul.
    Paul, the quote you call "meaningless marketing" contains several concrete statements that you could choose to debate if you didn't prefer arm-waving. I am more than happy to support every one of those statements with concrete examples if you want to have a real technical discussion. Rgds Rod
  41. Re: Getting the facts straight[ Go to top ]

    This is what Rod said


    Let me clarify the "apples-to-apples" part here. I don't believe that EJB/Spring is an apples to apples comparison because Spring's scope is much broader, it's much superior where overlap exists (DI, AOP, lifecycle) with the exception of some specialized remoting scenarios, it's more flexible and extensible, and it runs in and is suited to a much broader range of application architectures. Categorizing Spring (or EJB) as simply a DI container is simply wrong.

    Again, Java EE > EJB.


    I think this is meaningless marketing. You obviously disagree.

    Paul.

    Paul, the quote you call "meaningless marketing" contains several concrete statements that you could choose to debate if you didn't prefer arm-waving. I am more than happy to support every one of those statements with concrete examples if you want to have a real technical discussion.

    Rgds
    Rod
    Hi Rod, Thanks for responding.I understand it is difficult to respond in "sound bites" and I guessed that there was some substance behind the words you chose. But as an ensemble, without explanation ,this statement doesn't mean a whole lot. Here are some specific question that should help you to clarify further: 1. When You say Spring do you mean "The Spring Framework" as a whole, specific parts of the "Spring Framework" or Everything labeled "Spring" including other Spring projects like Spring Web Flow etc. 2. What does superior mean? Specifically in terms of DI? You assume that all EJB uses cases require the features you list. What about if you use neither DI, AOP or lifecycle methods with your EJBs? You are just interested in deploying your code as separate "modules". How does the comparison pair up then if any? 3. Considering that the two technologies can be used in differing use cases which do not overlap (are orthogonal), is this really apples-to-apples? What is the purpose of this comparison if any? 4. Java EE > EJB. By this I believe you mean that J2EE can be used without the EJB component model ("modules") and is better for it. I have coined the phrase that Java > Spring. By this I mean that monolithic J2EE Web Applications (WAR files) can be developed and deployed without the need for AOP, lifecycle methods, declarative transactions etc, and as a consequence are better for it. I would argue that a strong justification is needed to use any of these features in Spring. Do you agree? Paul.
  42. Re: Getting the facts straight[ Go to top ]

    Paul I'm glad that we are getting more specific.
    1. When You say Spring do you mean "The Spring Framework" as a whole, specific parts of the "Spring Framework" or Everything labeled "Spring" including other Spring projects like Spring Web Flow etc.
    In that context, the Spring Framework. Meaning the core enterprise component model (DI, AOP, core enterprise services such as transaction management). Spring Web Flow of course has no overlap with EJB. If you want security, Spring Security (formally Acegi). But EJB security isn't much used, in my experience, anyway, as it is very limited.
    2. What does superior mean? Specifically in terms of DI? You assume that all EJB uses cases require the features you list. What about if you use neither DI, AOP or lifecycle methods with your EJBs? You are just interested in deploying your code as separate "modules". How does the comparison pair up then if any?
    I was quite specific in my comment, which can be paraphrased as "[Spring] is superior where overlap exists with DI". So if you wish to debate that comment, let's compare the DI capabilities of each. Both EJB and Spring have DI features, I was commented on how I believe they compare.
    3. Considering that the two technologies can be used in differing use cases which do not overlap (are orthogonal), is this really apples-to-apples? What is the purpose of this comparison if any?
    Again, I was specific about my comments that "Spring is superior in the areas of overlap." If you want to debate those areas, that's fine.
    4. Java EE > EJB. By this I believe you mean that J2EE can be used without the EJB component model ("modules") and is better for it. I have coined the phrase that Java > Spring. By this I mean that monolithic J2EE Web Applications (WAR files) can be developed and deployed without the need for AOP, lifecycle methods, declarative transactions etc, and as a consequence are better for it. I would argue that a strong justification is needed to use any of these features in Spring. Do you agree?
    I agree that "J2EE can be used without the EJB component model ("modules") and is better for it". However, there are many features of an enterprise component model such as EJB that are useful, such as support for cross-cutting concerns, lifecycle methods, and declarative transactions. The problem is not the aspiration of EJB (which was fine), just the fact that it does a poor job of it. If you think that it's better to develop J2EE web applications without such a component model (building the necessary equivalents yourself) I disagree. In fact, I think you'd be better to use EJB than to do so (at least with EJB 3.0). But even better to use Spring :-) Rgds Rod
  43. Re: Getting the facts straight[ Go to top ]

    Paul

    I'm glad that we are getting more specific.

    1. When You say Spring do you mean "The Spring Framework" as a whole, specific parts of the "Spring Framework" or Everything labeled "Spring" including other Spring projects like Spring Web Flow etc.

    In that context, the Spring Framework. Meaning the core enterprise component model (DI, AOP, core enterprise services such as transaction management). Spring Web Flow of course has no overlap with EJB. If you want security, Spring Security (formally Acegi). But EJB security isn't much used, in my experience, anyway, as it is very limited.


    2. What does superior mean? Specifically in terms of DI? You assume that all EJB uses cases require the features you list. What about if you use neither DI, AOP or lifecycle methods with your EJBs? You are just interested in deploying your code as separate "modules". How does the comparison pair up then if any?

    I was quite specific in my comment, which can be paraphrased as "[Spring] is superior where overlap exists with DI". So if you wish to debate that comment, let's compare the DI capabilities of each. Both EJB and Spring have DI features, I was commented on how I believe they compare.

    3. Considering that the two technologies can be used in differing use cases which do not overlap (are orthogonal), is this really apples-to-apples? What is the purpose of this comparison if any?

    Again, I was specific about my comments that "Spring is superior in the areas of overlap." If you want to debate those areas, that's fine.


    4. Java EE > EJB. By this I believe you mean that J2EE can be used without the EJB component model ("modules") and is better for it. I have coined the phrase that Java > Spring. By this I mean that monolithic J2EE Web Applications (WAR files) can be developed and deployed without the need for AOP, lifecycle methods, declarative transactions etc, and as a consequence are better for it. I would argue that a strong justification is needed to use any of these features in Spring. Do you agree?

    I agree that "J2EE can be used without the EJB component model ("modules") and is better for it". However, there are many features of an enterprise component model such as EJB that are useful, such as support for cross-cutting concerns, lifecycle methods, and declarative transactions. The problem is not the aspiration of EJB (which was fine), just the fact that it does a poor job of it. If you think that it's better to develop J2EE web applications without such a component model (building the necessary equivalents yourself) I disagree. In fact, I think you'd be better to use EJB than to do so (at least with EJB 3.0). But even better to use Spring :-)

    Rgds
    Rod
    Hi Rod, I agree the devil is in the detail and we need to be specific. If I was to answer the question, "What is the best Framework(s) to use to build a J2EE Web Application. My answer would be it depends. In J2EE today people can choose from Grails, JRuby and Rails, Servlets+EJB+J2EE Services, Servlet+DI (Guice, Hivemind etc)+J2EE services+Hibernate+roll your own glue. Servlet+Spring(DI+ Libraries+glue)+Hibernate, Lift+Scala+... etc. So there is a lot to choose from. In making a choice my advice would be to keep things as simple as possible, and only use what you really need. I have been writing J2EE Web Applications since 1997, and I have never had a need for life cycle methods or AOP. In fact the only time I needed to worry about a distributed transaction is when we were using Tuxedo to do "the heavy lifting" and it solved all our problems nicely. In truth most J2EE Web Applications fall into the Grails end of the complexity spectrum (single database, no other transactional interfaces, web front end) and can be delivered very simply. I have used Pico Container, dabbbled with Xwork and used Spring as a DI framework and IMO they are all pretty much the same, I haven't used EJB DI, but from what I've read it is pretty much the same too. DI is a simple pattern. The only thing different and innovative I've seen in DI recently is Guice. You've skirted some of my questions, like why the focus on EJB? As you see above there are many frameworks where Spring functionality overlaps which you could choose to compare Spring to. Over the years I've learnt that "no answer" is sometimes as good as an answer. So I will take your response as is and not press you any further.
    If you think that it's better to develop J2EE web applications without such a component model (building the necessary equivalents yourself) I disagree. In fact, I think you'd be better to use EJB than to do so (at least with EJB 3.0). But even better to use Spring :-)
    We have to agree to disagree here. I have delivered several applications that used none of this stuff. In fact there is a very good book out there that shows you how to: J2 EE Open Source ToolkitJ2EE Open Source Toolkit. I have used Spring too, but only because I knew our Architects where likely to have heard of "Spring" and hence would have been less likely to kick up a fuss :). I guess marketing does have a role to play in this business:^) Good luck in the future. Paul.
  44. Re: Getting the facts straight[ Go to top ]

    We have to agree to disagree here. I have delivered several applications that used none of this stuff. In fact there is a very good book out there that shows you how to: J2 EE Open Source ToolkitJ2EE Open Source Toolkit. I have used Spring too, but only because I knew our Architects where likely to have heard of "Spring" and hence would have been less likely to kick up a fuss :).

    I guess marketing does have a role to play in this business:^)

    Good luck in the future.

    Paul.
    Sorry. Right publisher, wrong book. This is the book I meant: JavaTM Open Source Programming: with XDoclet, JUnit, WebWork, Hibernate: With XDoclet, JUnit, WebWork, Hibernate Paul.
  45. Re: Getting the facts straight[ Go to top ]

    Hi Rod,

    I agree the devil is in the detail and we need to be specific. If I was to answer the question, "What is the best Framework(s) to use to build a J2EE Web Application. My answer would be it depends. In J2EE today people can choose from Grails, JRuby and Rails, Servlets+EJB+J2EE Services, Servlet+DI (Guice, Hivemind etc)+J2EE services+Hibernate+roll your own glue. Servlet+Spring(DI+ Libraries+glue)+Hibernate, Lift+Scala+... etc.

    Did you notic that Grails is based on spring/hibernate (see also)?
    So there is a lot to choose from. In making a choice my advice would be to keep things as simple as possible, and only use what you really need.
    If you would be a bit more open minded, you wolud see that this what spring is good for.
    I have been writing J2EE Web Applications since 1997, and I have never had a need for life cycle methods or AOP. In fact the only time I needed to worry about a distributed transaction is when we were using Tuxedo to do "the heavy lifting" and it solved all our problems nicely. In truth most J2EE Web Applications fall into the Grails end of the complexity spectrum (single database, no other transactional interfaces, web front end) and can be delivered very simply.
    Then why the hell, did the Grails guys use spring???
    I have used Pico Container, dabbbled with Xwork and used Spring as a DI framework and IMO they are all pretty much the same, I haven't used EJB DI, but from what I've read it is pretty much the same too. DI is a simple pattern. The only thing different and innovative I've seen in DI recently is Guice.


    You've skirted some of my questions, like why the focus on EJB? As you see above there are many frameworks where Spring functionality overlaps which you could choose to compare Spring to. Over the years I've learnt that "no answer" is sometimes as good as an answer. So I will take your response as is and not press you any further.
    For me Guice would be an alternative, if I could switch to JDK1.5 and if they would have the same JEE industry support. But after the spring 2.5 release I see no need to switch.
    If you think that it's better to develop J2EE web applications without such a component model (building the necessary equivalents yourself) I disagree. In fact, I think you'd be better to use EJB than to do so (at least with EJB 3.0). But even better to use Spring :-)


    We have to agree to disagree here. I have delivered several applications that used none of this stuff. In fact there is a very good book out there that shows you how to: J2 EE Open Source ToolkitJ2EE Open Source Toolkit. I have used Spring too, but only because I knew our Architects where likely to have heard of "Spring" and hence would have been less likely to kick up a fuss :).
    I can't believe, that you used spring.
    I guess marketing does have a role to play in this business:^)

    Good luck in the future.

    Paul.
    Guessing is not enough. What means your complaint about the marketing thing?
  46. Re: Getting the facts straight[ Go to top ]

    Hi Benz,
    Then why the hell, did the Grails guys use spring???
    So Grails is Spring now? I guess in the same way that DI is Spring?
    Guessing is not enough. What means your complaint about the marketing thing?
    Posts like your just go to confirm my point. Paul.
  47. Re: Getting the facts straight[ Go to top ]

    So Grails is Spring now? I guess in the same way that DI is Spring?
    As I wrote, it's based on Spring. Why do you change my words? Personally, I don't use Spring as a DI framework. I use it, to avoid vendor lock in (and so I had to use DI). Now that sounds like marketing blah blah!? But what that means for me is stated here and is very important for my daily productivity (no marketing, real live experience). You could do the whole thing without spring? Sure, but why should I reinvent that big wheel? Spring has already the support for all the different J2EE environments. So why, what is wrong with spring???
    Posts like your just go to confirm my point.
    I like your postings about dynamic languages (not agreeing), but I don't understand your complaints about Spring and JBoss. What is your message here? There is marketing??? btw, there is still a question open.
  48. Re: Getting the facts straight[ Go to top ]

    Posts like your just go to confirm my point.
    I like your postings about dynamic languages (not agreeing), but I don't understand your complaints about Spring and JBoss. What is your message here? There is marketing???
    Nothing is wrong with marketing per se, but there is something particularly distasteful (IMO) about supposedly community based open source projects fighting over the old J2EE App. Server Market the way Spring and JBoss are. You've heard what Rod as said here. In other threads you've heard the likes of Gavin King. There messages are the same. Use our product for everything we will solve all your problems, we have the J2EE silver bullet. Now for the discerning this message is probably not a problem. But these people know who they are marketing to. It is not us, it is the likes of Managers and Architects. The same people who made purchase decisions for Weblogic or Websphere. The "strategic" decision makers who make "strategic" decisions across the entire enterprise. These people will enforce the use of "Spring" or "JBoss Seam" for everything, making them defacto standards and Rod and/or Gavin will be the next Marc McFluery, laughing all the way to the bank. Paul.
  49. Re: Getting the facts straight[ Go to top ]

    Posts like your just go to confirm my point.
    I like your postings about dynamic languages (not agreeing), but I don't understand your complaints about Spring and JBoss. What is your message here? There is marketing???



    Nothing is wrong with marketing per se, but there is something particularly distasteful (IMO) about supposedly community based open source projects fighting over the old J2EE App. Server Market the way Spring and JBoss are.

    You've heard what Rod as said here. In other threads you've heard the likes of Gavin King. There messages are the same. Use our product for everything we will solve all your problems, we have the J2EE silver bullet.

    Now for the discerning this message is probably not a problem. But these people know who they are marketing to. It is not us, it is the likes of Managers and Architects. The same people who made purchase decisions for Weblogic or Websphere. The "strategic" decision makers who make "strategic" decisions across the entire enterprise. These people will enforce the use of "Spring" or "JBoss Seam" for everything, making them defacto standards and Rod and/or Gavin will be the next Marc McFluery, laughing all the way to the bank.

    Paul.
    That's a clear message that I can understand (but Rod and Gavin seem to be nice guys). Unfortunately the mangagers/architects in my projects don't like Spring...
  50. Re: Portability[ Go to top ]

    it is not AOP although it wraps... I could continue.
    Paul, what AOP does Spring wrap?
  51. Re: Portability[ Go to top ]

    it is not AOP although it wraps... I could continue.


    Paul, what AOP does Spring wrap?
    Did Spring implement its own AOP? I think you're right. Using the dynamic proxy API (much like JBoss did I think). Not as powerful as AspectJ if my memory serves me right, but easier to implement. So 1 out of 5+ services implemented by Spring itself rather than wrapping the work of others. I'll say it for the last time. I actually like Springs code. It is well designed. A good DI framework, with well thought out "glue code". It is the marketing and mis-representation that I don't like. This fanaticism would be funny, but for the fact that you guys are really acting like lemmings. It's actually scary. Let's see if your great leader chooses to turn up again. Over and out. P.
  52. Re: Portability[ Go to top ]

    Beyond a branding exercise what is Spring exactly?
    Since you keep asking what it is, and keep complaining that it isn't such-and-such, or is marketed misleadingly, here is a rundown of some of the relevant things that Spring provides: 1. A container mechanism allowing you to assemble objects of a granularity of your choosing, each of which may have an arbitrary scope dependent on your application requirements. Yes, this is IoC. No-one ever claimed Rod Johnson invented IoC. No-one ever claimed Spring was the only way to do this. 2. Supporting the IoC mechanism, a rich set of APIs that allow you to solve common problems elegantly (pre/post-processing your beans, subsituting other instances at runtime, build beans from arbitrary scripting languages, factory instances, subsituting properties at runtime, creation/destruction hooks, validating and converting supplied instances, wiring in AOP behaviour etc. etc.). All of this is no doubt acheivable without Spring - but using Spring provides a nice consistent approach to all of the above. 3. A container mechanism that is independent of any aspect of your runtime environment or any specific configuration mechanism. Your beans can be wired up just as well in Jetty, WebSphere, JUnit tests or a Swing client app. 4. Outside of the basic IoC mechanisms, there is a cornucopia of complementary supporting classes to do common things, such as: - Pool and hotswap object instances - Trace and monitor performance - Export beans to JMX - Expose services over arbitrary remoting strategies - Simple/flexible mechanisms for interacting with JMS, EJB, JCA, JavaMail, common ORM/DAO libraries and scheduling - Lest we forget, the whole christmas tree of Spring MVC capability, validation, resource abstraction 5. Several complementary projects (Security, Webflow, OSGi support though Dynamic-modules etc.) that extend and enhance the core Spring libraries with further useful functionality, again implemented in a complementary way. 6. Wide-ranging support from other projects that provide nice third-party integration or functionalty built on top of Spring (GigaSpaces, Terracotta, Grails, etc. etc.)
    Dependency Injection is merely a design pattern that allows for the construction of objects in an OO fashion when using an early bound language like Java. You don't need Spring to do DI.
    To reduce Spring to *just* object construction, and then complain that it doesn't provide any value or is less capable than other frameworks is one hell of a Straw man. The fact is, there is a lot of value to be had in Spring. I mean, even if you just use org.springframework.util.*, there is some definite value in there ;) With a bit of work you could acheive the same things without Spring, but some of us actually enjoy writing applications around it, like a consistent and portable approach, and appreciate not having to invent solutions to common problems time and again.
    To assemble "components" or "modules" at deployment time, requires a means of packaging components separately at compile time, and some means of component/module discovery and binding at runtime. Both OSGi and EJB address this model of deployment, DI frameworks like Spring do not.
    But this is just discovery - you don't need either EJB or OSGi to do this ;) Just teasing. But if you need runtime discovery, you can do simple module discovery on startup and for more advanced stuff why not use OSGi? Why is it a bad thing that Spring not try to address problems for which there is already a good solution, but instead focusing on providing good support and flexibility as part of the framework?
    So 1 out of 5+ services implemented by Spring itself rather than wrapping the work of others.
    Hang on, is this actually your objection? That Spring generally provides a convenience layer above other implementations, rather than out-and-out providing an implementation itself? Because that is a pretty strange objection.
    Java > Spring
    I don't even understand what you're getting at...
    It is the marketing and mis-representation that I don't like.
    Provide a link to some misrepresentation. Please.
  53. Re: Portability[ Go to top ]

    In fact, SpringSource is playing a leading role in taking OSGi to the server-side. As witness the Spring Dynamic Modules for OSGi project ...
    Is this a deja-vu or a marketing joke? Are you even aware of all the pitfalls that are there for OSGi and JEE (aka server-side) integration? A simple component model (and that's what your project currently is) ain't gonna solve them. ;-)
  54. Re: Portability[ Go to top ]

    I'm not a defender of EJB, but so called facts like these are nothing more than marketing in my opinion. In most of your advocacy of Spring you could replace the word Spring with DI Framework and your facts would read the same. Branding a design pattern as though it is a product is misleading in my opinion and makes me question your motives. You simply aren't comparing apples with apples.
    Paul, in another thread, you appear to agree that "EJB will become just another DI framework just like Spring or Guice but using standardised annotations."
  55. I'm not a defender of EJB, but so called facts like these are nothing more than marketing in my opinion. In most of your advocacy of Spring you could replace the word Spring with DI Framework and your facts would read the same. Branding a design pattern as though it is a product is misleading in my opinion and makes me question your motives. You simply aren't comparing apples with apples.


    Paul, in another thread, you appear to agree that "EJB will become just another DI framework just like Spring or Guice but using standardised annotations."
    Yes George, I said a lot on that thread. I asked the question of Reza "Has Sun repositioned EJB?". Especially since everyone was comparing EJB to Spring. His response was no. EJB does do DI now but it is still a component model. So from the horses mouth EJB is not just a DI framework. Let me give an alternative explanation for why Spring skills are outstripping EJB skills. Most people who started out using EJB never needed it in the first place. People woke up to the idea that they didn't need distributed components to scale. They could get away with building single WAR monolithic applications, they didn't need the JEE component model. All they needed was JEE services, and DI provides a neat way to inject services into your code. This is the real reason. People who really need components will look to OSGi not Spring. So why did they all start using EJB in the first place when they didn't need it? Marketing. Now Spring are marketing themselves in much the same way and I'm sure that there are plenty of Spring projects out there which are over complex using a bunch of stuff they don't need (speculation, but probably true). I've noticed that Rod as skirted the issue. He says that he isn't the one making the apple to pears comparison, but anyone who has followed EJB vs Spring discussions on TSS will clearly see that Rod and the other Spring advocates clearly have been making this false comparison. Why? I have stated two facts in my previous post. Rod now seems to agree that Spring is not a like for like replacement for EJB, but he is silent on my first point. DI is just a design pattern. I've used Spring and it is a good toolkit. Most of the stuff in Spring you could write yourself, and DI is a nice way to wire it all together. But spring is not that different than writing a big "init" method yourself that configures a bunch of stuff before executing your code. I'm sure that most of the Spring toolkit could be used with Guice or any other DI framework. It's just Java code. All this talk of POJOs, light weight container etc is meaningless marketing and branding in my opinion. Just like calling a vacuum cleaner a "Hoover". If you say the brand name often enough it will stick. Paul.
  56. Most people who started out using EJB never needed it in the first place
    Actually I think this is plain wrong. People used EJB not because it is a component model and not because it supports remoting. People started to use because it provided (and still provides) extremely powerful transaction management, lifecycle management and transparent caller identity, authentication and to some extent authorization. Building and testing these aspects yourself tends to be very laboursome and error prone. Even spring took a lot of time to implement these in a decent and robust fashion. But people jumped the spring bandwagon even before it was a decent replacement for what you get from EJB, because it was simple (then). The funny thing is: It is not simple any more. It cannot be simple any more, because the actual problemscape it addresses is complex. This is probably the only real pattern I can see in IT: Technologies are ditched to go for something "simpler" that by the time it gets "mature" has outgrown it predecessor in complexity. I think it has something to do with how people learn. Think about other examples: SOAP (simpler than CORBA)! C++ (simpler than C - I actually heard this! People actually believed superset would be simpler than the subset!).
  57. Actually I think this is plain wrong. People used EJB not because it is a component model and not because it supports remoting.
    I guess people have different experience of the merits of the early EJB versions. Anecdotally, I've seen some successes, but every clunky, failing, impossible-to-maintain EJB application I've ever seen was a single server web application with entity beans for database access. Of course, anecdotal evidence is no proof at all - perhaps a third-party survey is called for ;) But I've seen a few cases of EJB-based apps being built purely on the basis that that was what people thought they had to do. I guess the reason for Spring's initial success is that it rode the crest of a wave of developers that felt that if they didn't actually *need* all of the great features you mention, and they could deploy their app as a war and even (gasp) just use plain JDBC for database access, then they should be allowed to do so. You're right that those extra things are hard to implement on your own - but if you genuinely don't need them then that's a moot point. Plus - and this is a big one from my personal experience - it let you structure a lightweight application in such a way that you could seamlessly drop in EJBs at a later date if it turned out they were necessary. The migration path from simple -> complex became a lot less painful and risky.
    The funny thing is: It is not simple any more. It cannot be simple any more, because the actual problemscape it addresses is complex. This is probably the only real pattern I can see in IT: Technologies are ditched to go for something "simpler" that by the time it gets "mature" has outgrown it predecessor in complexity.
    This is a very good point. Also, as the framework has grown, the position has moved from "are you sure you need EJB in this case?" to "are you sure you even need EJB at all?". Once you have a big solution that solves the hard problems, you have to wonder if there isn't a simpler way of doing all those simple problems... You can see why people like G/Rails so much ;)
  58. The funny thing is: It is not simple any more. It cannot be simple any more, because the actual problemscape it addresses is complex.
    It is quite possible to have a technology which is simple to use even if it can help to solve complex problems. It's a question of having a modular design and using abstractions appropriately to conceal complexity. Adding new capabilities does not necessarily make something more complex to use. Take for example the addition (back in Spring 1.1) of JMX support. It became possible to use "JMX exporters" to transparently export Spring managed objects as JMX MBeans. If you didn't want that capability, you didn't need to use it or even learn it. But if you did want that capability, you could suddenly achieve something very useful with a lot less effort than you would previously have required. An additional capability; either no change in usage or simpler usage. Another proof point: in Spring 2.5 the sample applications carried over from Spring 1.0 contain significantly less code and less configuration than the original version. Far from getting more complex to use, as it's gotten broader in scope and more capable, Spring has gotten easier. Just thought some specific examples might be better than arm-waving... Rgds Rod
  59. It is quite possible to have a technology which is simple to use even if it can help to solve complex problems. It's a question of having a modular design and using abstractions appropriately to conceal complexity.
    Sorry that I am still pessimistic. Because to actually use a technology, for most IT scenarios you have to understand a fair bit of what they do internally, and quite often you also need the technology they try to abstract from in the first place. The simple reason is that most abstractions I came across in various IT technologies are "leaking" or "broken". On top of that, to use "configuration-by-default", which is generally the reason for the "simpler" so many people claim nowadays. They are not simpler, though, only the learning curve may be more user friendly: They may make simple things simple, but not necessarily hard things more simple.
  60. This is probably the only real pattern I can see in IT: Technologies are ditched to go for something "simpler" that by the time it gets "mature" has outgrown it predecessor in complexity.
    I think that's a bit overly pessimistic. There is real progress over time, although it isn't always smooth. For example, EJB in its time achieved a number of things in a simpler way than the CORBA technology that partly inspired it. IMO the real problem is that business requirements demand ever more complex applications, meaning that even as successive generations of technologies deliver real improvements, IT still struggles to keep up. Rgds Rod
  61. Most people who started out using EJB never needed it in the first place


    Actually I think this is plain wrong. People used EJB not because it is a component model and not because it supports remoting. People started to use because it provided (and still provides) extremely powerful transaction management, lifecycle management and transparent caller identity, authentication and to some extent authorization. Building and testing these aspects yourself tends to be very laboursome and error prone.
    Hi Karl, Of course you can't generalize, but the features you speak of were around in high performance transactional systems long before EJB. Take a look at Tuxedo for instance or CICS. How many people were writing transactional systems before J2EE? Answer: The people that needed them. The declarative model of EJB made using these features easy, but I still say that most people that used them (with a single database) didn't need them. And if you do need them then why not just call a library? This is all that a J2EE service is, a library with a common interface. Instantiate the service class and go ahead and use it. It is not that hard, this is what Spring does under the covers. I actually agree with Rod, that through good design you can do a lot with very simple code. The point I was making earlier was with regards to the marketing of Spring. I have read Rods early books on J2EE and EJB and they are good. I think since then the Spring bandwagon has got away with itself and has perhaps the message of writing good clean simple code has been lost. This is what I meant by: Java > Spring. I haven't looked at Spring in a while, but I'm sure that there are plenty Spring advocates who are using Spring to produce over complex systems using Spring features they don't need. I also believe this comparison with EJB is a false one, and has more to do with promoting SpringSources commercial interests then honest technical analysis. Paul.
  62. I also believe this comparison with EJB is a false one, and has more to do with promoting SpringSources commercial interests then honest technical analysis.

    Paul.
    Spring does compete with EJB on two core areas: dependency injection, and declarative provision of enterprise services via AOP (in the case of Spring) or EJB container. Spring has more mindshare at this time in these two areas. That is why, I reckon, even the JBoss guys call for Spring being "standardised".
  63. The point I was making earlier was with regards to the marketing of Spring. I have read Rods early books on J2EE and EJB and they are good. I think since then the Spring bandwagon has got away with itself and has perhaps the message of writing good clean simple code has been lost
    Paul, I think this is worth discussion. I've read most of your posts recently, but I'm not sure what message that you think SpringSource (I have no ties to it) is promoting now. The history as I see it is that Rod's initial book in late 2002 offered a better, simpler way to build applications on top of J2EE. As you point out, there was nothing revolutionary in the book, but as others have argued, what Spring provides is and has been very useful to a lot of people. The book also argued that EJBs aren't the right solution for a lot of the use cases where they were being applied. As far as I can tell, this concept of a better, simpler way to build on JEE is still the dominant message from the Spring folks. And the argument regarding EJB has perhaps changed from "EJB2's aren't frequently the right choice" to "EJB3's, while being a standard, don't offer the features of a non-standard solution". But I think that latter point is very secondary to the former point. You also raised the point of what "is" Spring - I still describe it as I did in 2003 - an application framework on top of J2EE / now JEE. The DI container aspect is certainly an important part of that, but I think the more critical part is a consistent design approach towards simplifying JEE usage and building Java applications in general. Also, I say that it's built on JEE - that's not totally true, but I've run into too many stupid "architects" who see Spring and JEE as an either-or choice. So I still don't think the Spring folks are promoting anything revolutionary or ground-breaking. I think what most users (would be nice if terms like fanboys/zealots/lemmings/etc. weren't used, since I think that immediately discredits the speaker) find appealing is how useful Spring is. That doesn't mean Spring is the best approach, but until something is offered that is more useful and probably more simple as well, I think people will keep using Spring.
  64. Hi Rubin, I read your response and your perspective is balanced and honest. My difficulty is that "clean simple design" is not a brand or a product. SpringSource today is selling both a product and a brand. You cannot sell "clean simple design"! Everyone needs to read Rods words and come to there own conclusion, but if you look at the responses here you will see that I'm not the only one question SpringSources motives and their marketing message. To me their marketing message is akin to selling "Snake Oil" or a "Silver Bullet", much like the original EJB message. At least in this regard Spring versus EJB is a valid comparison! I take your point on the name calling (but I was not the only one :^)). I agree that this is a valid debate that needs to be had (I've blogged as much in the past), and SpringSource has every opportunity to set the record straight right here in public. Paul.
  65. Re: Portability[ Go to top ]

    I'm not a defender of EJB, but so called facts like these are nothing more than marketing in my opinion.
    Indeed, and some of the bluff is called: http://www.infoq.com/news/2008/02/ejb-spring-job-listings-trends
  66. Portability[ Go to top ]

    How on planet earth does a non-standard environment mean greater portability, and if you throw out the 'extensions' that app server vendors have placed on their platforms, my question is where do you deploy other than Tomcat and achieve portability?
    Spring runs in any Java EE server, without any vendor extensions. It runs (obviously without annotation support) even in pre Java EE5/Java 5 environments. It runs in any web container. It runs (and is used in many environments) without any other container. It runs in test environments. It builds on Java EE standards as extension points, including the Servlet API and JCA. The facts are, however, perhaps less interesting than your rhetoric.
  67. Re: Portability[ Go to top ]

    How on planet earth does a non-standard environment mean greater portability, and if you throw out the 'extensions' that app server vendors have placed on their platforms, my question is where do you deploy other than Tomcat and achieve portability?

    Spring runs in any Java EE server, without any vendor extensions. It runs (obviously without annotation support) even in pre Java EE5/Java 5 environments. It runs in any web container. It runs (and is used in many environments) without any other container. It runs in test environments. It builds on Java EE standards as extension points, including the Servlet API and JCA.

    The facts are, however, perhaps less interesting than your rhetoric.
    But your original point that wound up the poster was "Spring is far more portable than EJB". I do have my problems with the statement as well. Of course Spring is portable, but why would it be "more portable" than a well composed EJB? Depends what you do, right? With an EJB, I could for example assume that I am inside some specific container and use some classes only existent in this server. I could do the same kind of thing with Spring. One could say, that the IoC programming model, to a certain extent, encourages you to stay portable, but that is about it.
  68. Re: Portability[ Go to top ]

    Surely the test of the statement that "Spring is far more portable than EJB" is whether Spring technology runs in more places than EJB technology. I explained why it does with concrete examples.
  69. Re: Portability[ Go to top ]

    Surely the test of the statement that "Spring is far more portable than EJB" is whether Spring technology runs in more places than EJB technology. I explained why it does with concrete examples.
    Ah well, that is a weak comparison isn't it. An EJB runs in any EJB container, if written properly, while a spring application runs within any Spring Container, if written properly :-). The "portability" you are refering to is actually configurability (which is not much of a surprise, because IoC is a glorified term for push configuration) of the environment. This "configurability" is simply not in scope of the EJB definition. It would be in the scope of an application server provider, but it is tough to tell, why you might want a different JPA, Connection Pool, Naming or whatever provider than what the container delivers anyway (with the notable exception of security providers).
  70. Re: Portability[ Go to top ]

    Ah well, that is a weak comparison isn't it. An EJB runs in any EJB container, if written properly, while a spring application runs within any Spring Container, if written properly :-).
    So you are talking about portability of applications, not the component model itself. I was talking about the latter. However, applications using Spring are also likely to be more portable. Prior to EJB 3.x code in any EJB application is totally tied to EJB and can't run anywhere else. But I doubt that anyone disagrees that EJB 2.x is deservedly obsolete. Things are better in EJB 3.0, but there's still more likelihood of depending explicitly on EJB constructs than Spring constructs because of the limitations of the EJB DI and interception models. Spring's more advanced AOP model (no need for the fragile invasive @Interceptors approach) and more flexible DI (Method Injection to avoid the need for explicit lookup, injectable objects not limited to those bound in JNDI, pluggable object scopes etc.) typically limits the need to use Spring APIs and constructs where the core component model is concerned. (Using the various class libraries that Spring offers is a different question, but those are not directly comparable with EJB and they are perfectly compatible with EJB.) You haven't disputed the evidence that Spring runs in more places than EJB. So even if components assume the existence of Spring they are much more likely to be able to run in Tomcat, other servlet containers, any Java EE server etc. Furthermore, EJB still lacks some basic features necessary to authoring of portable components, which is why typically you will find that applications using the EJB component model are less portable than those using Spring. For example, how do you get something to execute when an EJB container starts up? Typically, you either have a fragile dependence on something like a Servlet listener or you resort to non-portable APIs.
    The "portability" you are refering to is actually configurability (which is not much of a surprise, because IoC is a glorified term for push configuration) of the environment.
    I have no idea what you mean by this. Rgds Rod
  71. Re: Portability[ Go to top ]


    So you are talking about portability of applications, not the component model itself. I was talking about the latter.

    However, applications using Spring are also likely to be more portable. Prior to EJB 3.x code in any EJB application is totally tied to EJB and can't run anywhere else. But I doubt that anyone disagrees that EJB 2.x is deservedly obsolete. Things are better in EJB 3.0, but there's still more likelihood of depending explicitly on EJB constructs than Spring constructs because of the limitations of the EJB DI and interception models. Spring's more advanced AOP model (no need for the fragile invasive @Interceptors approach) and more flexible DI (Method Injection to avoid the need for explicit lookup, injectable objects not limited to those bound in JNDI, pluggable object scopes etc.) typically limits the need to use Spring APIs and constructs where the core component model is concerned. (Using the various class libraries that Spring offers is a different question, but those are not directly comparable with EJB and they are perfectly compatible with EJB.)

    You haven't disputed the evidence that Spring runs in more places than EJB. So even if components assume the existence of Spring they are much more likely to be able to run in Tomcat, other servlet containers, any Java EE server etc.

    Furthermore, EJB still lacks some basic features necessary to authoring of portable components, which is why typically you will find that applications using the EJB component model are less portable than those using Spring. For example, how do you get something to execute when an EJB container starts up? Typically, you either have a fragile dependence on something like a Servlet listener or you resort to non-portable APIs.

    Of course an EJB depends on bean constructs. That is why it is an EJB in the first place. Of course there is no such thing like a "Spring Object". That would defy the Pojo Idea wouldn't it? That does make the application more portable in the sense that you can use another stack of actual service implementations on it, since they are either JEE standard stuff or abstracted by spring or abstracted by something you write yourself. "How do you get something to execute when an EJB container starts up?" is the wrong question. You don't! Because it is not in the spec. If your outside the box, your outside the box. That's very much like "How do you get a JNDI connection with a hard coded JNDI name if the name changes".
    The "portability" you are refering to is actually configurability (which is not much of a surprise, because IoC is a glorified term for push configuration) of the environment.

    I have no idea what you mean by this.
    The portability of Spring is basically due to the configurability of the resources, namely IoC or DI or push configuration which is what the former acronyms really mean. DI means that you "push" something into an object instance configuratively (and reflectively) instead of "pulling" the configuration into the object and letting it configure itself. So using Spring you can "push" another connection pool implementation (or connection) into your bean, another identity asserter and so on. But: Beans to run in Spring will very seldomly run in a meaningful way without Spring. While they are not explicetley dependent on the container, they are very often implicitely dependent on it - simply because noone in his right mind would go through the exercise of writing the code you need to wire up all the stuff you'd need to wire up to use them without DI! One of the nicest things you can do with Spring is of course to run a subconfiguration for development or tests which is great for productivity. So my notion is: You get flexibility and configurability. But portability is a different animal.
  72. Re: Portability[ Go to top ]

    Hi Karl,
    Of course an EJB depends on bean constructs. That is why it is an EJB in the first place. Of course there is no such thing like a "Spring Object". That would defy the Pojo Idea wouldn't it? That does make the application more portable in the sense that you can use another stack of actual service implementations on it, since they are either JEE standard stuff or abstracted by spring or abstracted by something you write yourself.
    You are correct. EJBs are portable between EJB containers by definition. A DI Container does not exist this is just marketing nonsense. What does exist is the DI pattern that allows you to inject dependencies into Java objects. And like you say by definition this means that your code will run anywhere Java will run as long as the dependencies are satisfied at object construction (using an object factory for instance). This is not a property of Spring per se, but a property of the DI pattern. I first came across this pattern when writing a J2EE web application using Pico container, others have used the same pattern and J2EE with Hivemind, XWork, Guice etc in the same way.
    The portability of Spring is basically due to the configurability of the resources, namely IoC or DI or push configuration which is wlockqhat the former acronyms really mean. DI means that you "push" something into an object instance configuratively (and reflectively) instead of "pulling" the configuration into the object and letting it configure itself. So using Spring you can "push" another connection pool implementation (or connection) into your bean, another identity asserter and so on. But: Beans to run in Spring will very seldomly run in a meaningful way without Spring.
    Once you go beyond the basic DI feature your code becomes coupled to the Spring framework, as you rightly point out (which is why I have never used anything other then the basic Spring bean factories avoiding the Spring libraries, and the glue code). This happens in a number of ways: annotations, XML, Spring libraries, Spring glue code etc. These are all non-standard, so where ever you move your code to you will need to take Spring with you. You are correct on this too. Is this Rods idea of portability? Like I said marketing nonsense. Paul.
  73. Re: myopia[ Go to top ]

    Rod, The basic understanding from this thread that you think portability has to do with where the Spring development environment runs as opposed to the apps that are built from it, or from EJBs, is beyond comical... I intended to make this point some days ago, but I guess when it needs to be said, someone will say it, just didn't expect it to be u, why in the world would anyone care how many platforms u have certified on? The only thing that matters is portability of components so we dont have a duopoly again in the middleware space and definitely not a monopoly in favor of Spring... I seriously would like a reasoned explanation why Spring is not getting in to the deployment space and/or working on EJB 3.1 support, outside of Tomcat, or is ubiquity the only way the valuation works its way out... I think the developer community has the best insight in to IT decisions, and they have, in large measures, voted with their feet, to support Spring, but it really is about time, to lay out a business model that can be supported by the JEE community for why Spring should be given a seat at the table, when u r running an insurgency campaign against the main JEE technology.... Maybe I am paranoid, but the longer u go on obfuscating the path of Spring to success, and avoiding a compromise the longer we have to sit and defend, its getting to be a bore, to talk with u and the Springites....
  74. Re: myopia[ Go to top ]

    The problem is that EJB is about stateless session bean, stateful session bean, entity bean and message driven bean, whether it is EJB3, EJB2 or EJB1. Even Hibernate started as EJB3 (yes, we know there was once a slogan caled "Hibernate is EJB3"), it ended as JPA.
  75. Re: myopia[ Go to top ]

    Rod,

    The basic understanding from this thread that you think portability has to do with where the Spring development environment runs as opposed to the apps that are built from it, or from EJBs, is beyond comical...

    I intended to make this point some days ago, but I guess when it needs to be said, someone will say it, just didn't expect it to be u, why in the world would anyone care how many platforms u have certified on?

    The only thing that matters is portability of components so we dont have a duopoly again in the middleware space and definitely not a monopoly in favor of Spring...

    I seriously would like a reasoned explanation why Spring is not getting in to the deployment space and/or working on EJB 3.1 support, outside of Tomcat, or is ubiquity the only way the valuation works its way out...

    I think the developer community has the best insight in to IT decisions, and they have, in large measures, voted with their feet, to support Spring, but it really is about time, to lay out a business model that can be supported by the JEE community for why Spring should be given a seat at the table, when u r running an insurgency campaign against the main JEE technology....

    Maybe I am paranoid, but the longer u go on obfuscating the path of Spring to success, and avoiding a compromise the longer we have to sit and defend, its getting to be a bore, to talk with u and the Springites....
    What portability means to me: - develop on Tomcat/IntelliJ, - test with TestNG, - deploy on Websphere 5.1. In fact I also migrated EJB1.x applications to other application servers. Let's say, it was possible. Last year I migrated a hivemind application to spring - it was a pleasure. (Disclaimer: I still have no connectios to spring, I'm just a happy lemming)
  76. Re: myopia[ Go to top ]


    What portability means to me:

    - develop on Tomcat/IntelliJ,
    - test with TestNG,
    - deploy on Websphere 5.1.
    Hm , to me it would mean "develop on spring", "move to another application framework and application server", which is near impossible when you use spring's advanced features. But this kind of "portability" is portability by definition. You configure your application differently. Strangely enough, changing things in springs config files seems to mean "portability" for the same people who think the need to change things in EJB deployment descriptors makes them not portable. Well, even develop on tomcat -> deploy on Websphere has its pitfalls. Not so much in Spring itself, but in subtly different behavior and features used in transaction management implementations, strange things happening when you switch your implementations and so on.

    In fact I also migrated EJB1.x applications to other application servers. Let's say, it was possible.
    Last year I migrated a hivemind application to spring - it was a pleasure.

    (Disclaimer: I still have no connectios to spring, I'm just a happy lemming)
    Of course, but that only is a pleasure because Spring is a functional superset of hivemind. Now you start using the advanced features, AOP, add ons, glue code, and suddenly someone says: Let's port the stuff to hivemind2.
  77. Re: myopia[ Go to top ]

    What portability means to me:

    - develop on Tomcat/IntelliJ,
    - test with TestNG,
    - deploy on Websphere 5.1.
    Hm , to me it would mean "develop on spring", "move to another application framework and application server", which is near impossible when you use spring's advanced features. But this kind of "portability" is portability by definition.

    You configure your application differently. Strangely enough, changing things in springs config files seems to mean "portability" for the same people who think the need to change things in EJB deployment descriptors makes them not portable.
    Well, if your portability can do what my protability can do (without pain), you're a lucky guy, just like me.
    Well, even develop on tomcat -> deploy on Websphere has its pitfalls. Not so much in Spring itself, but in subtly different behavior and features used in transaction management implementations, strange things happening when you switch your implementations and so on.
    In fact we had the same concerns, but in practice it works great! Maybe that's because Websphere has also Tomcat inside. We have no 2-Phase-Commit for the JMS stuff, but that's ok for development.
    In fact I also migrated EJB1.x applications to other application servers. Let's say, it was possible.
    Last year I migrated a hivemind application to spring - it was a pleasure.

    (Disclaimer: I still have no connectios to spring, I'm just a happy lemming)

    Of course, but that only is a pleasure because Spring is a functional superset of hivemind. Now you start using
    the advanced features,
    What would that be? I don't use any advanced features.
    AOP,
    Why would I use that ugly stuff directly (altough they use the aopaliance api...)
    add ons,
    What would that be?
    glue code,
    I don't have any glue code.
    and suddenly someone says: Let's port the stuff to hivemind2.
    Well, that person would say move to Guice or Qi4j.
  78. Re: myopia[ Go to top ]

    Douglas
    The basic understanding from this thread that you think portability has to do with where the Spring development environment runs as opposed to the apps that are built from it, or from EJBs, is beyond comical...
    Such strong views, and yet you have failed in the "basic understanding" of what Spring is. Spring is not a development environment. I have given concrete examples of both where the Spring component model runs and where applications running the Spring component model run. You cite no evidence, although your insults are as amusing as ever. Some examples of development environments that may be helpful: - Eclipse - NetBeans - JBuilder Which one of these you use is unlikely to affect the portability of an application at runtime as development environments are not part of the runtime. Spring is part of the runtime.
    I intended to make this point some days ago, but I guess when it needs to be said, someone will say it, just didn't expect it to be u, why in the world would anyone care how many platforms u have certified on?
    Many people care very much because it helps them be freer in choosing their deployment platform. You presumably don't care (and that's fine), but you should not presume to speak for others.
    I seriously would like a reasoned explanation why Spring is not getting in to the deployment space and/or working on EJB 3.1 support, outside of Tomcat, or is ubiquity the only way the valuation works its way out...
    Ubiquity is what the Spring community wants. People value the fact that when you use Spring you are more likely to be able to move your application between Tomcat, WebLogic, WebSphere, JBoss/whatever, given you the choice of deployment platform that best suits your needs. Note that Spring 2.5 supports @Resource, @PostConstruct, @TransactionAttribute and other Java EE 5/EJB 3.0 annotations. EJB 3.1 is non-final, so no one "supports" it.
  79. Re: myopia[ Go to top ]

    Ubiquity is what the Spring community wants. People value the fact that when you use Spring you are more likely to be able to move your application between Tomcat, WebLogic, WebSphere, JBoss/whatever, given you the choice of deployment platform that best suits your needs.
    I really don't think that this is so much of an issue for production deployment. Target servers change seldomly. The real benefit of Spring is the possibility to develop in a different environment and to develop or test in a configuration subset. As such, it is *not* the Spring component model that is portable. It is Spring *itself* that is or may be portable. You have built an environment that is portable between various providers of JEE services. It is fine to say that this kind of portability is the one that really matters. For me, when I develop JEE5 EJBs this kind of portability is just not very interesting. When I develop some other application it may well be.
  80. Re: Portability[ Go to top ]

    You are correct. EJBs are portable between EJB containers by definition.
    Have you ever tried to port an EJB application of any complexity between application servers?? Earlier in the thread I mentioned some of the reasons that EJB apps typically aren't completely portable.
  81. Re: Portability[ Go to top ]

    You are correct. EJBs are portable between EJB containers by definition.

    Have you ever tried to port an EJB application of any complexity between application servers?? Earlier in the thread I mentioned some of the reasons that EJB apps typically aren't completely portable.
    Yes. I have indeed. And you are right it may be painful. But the main reason for it is not, that this is not possible, but that people just did stuff that they should not have done in the first place. Hard coded JNDI names, Proprietary extensions of (yuck) entity beans, Reliance on pass-by-reference where they shouldn't, usage of 2-pc transaction emulation, bytecode modification.... The DI pattern encourages you to avoid some of these pitfalls. Being notoriously pessimistic, I don't think it will make much of a difference in the real world. Not every project is led by someone as competent (no irony!) as Rod Johnson....
  82. Re: Portability[ Go to top ]

    Karl I should have made it clearer that the comment I was disagreeing with ("EJBs are portable between EJB containers by definition") was made by Paul, not you. Rgds Rod
  83. ReallyusefulNewFeatures.jee[ Go to top ]

    I make bold to say EJB/JEE is heading towards the bus stop MS left years back(yes you read that right). As a long time .Net/COM+ developer who had to migrate to J2EE because of the EJB hype, I find it funny that most developers on the J2EE platform can't just see that the current J2EE spec sucks!A test of the ease of use of any product/frameworks/whatever is the relative ease with which a new user can get an app up and running.The whole array of confusing specs,frameworks,APIs that one has to learn to implement the simplest functionality in J2EE is at best annoying.My current impression of a J2EE project now is it really gives you the feel of an academic exercise.What with over-engineered APIs and frameworks in the name of OOP purism, ardent refusal to implement complementary technologies from competitors(why were the JSR guys afraid of including the .Net style delegate in the specs when they picked on annotations?),proliferation of crappy specs and a mountain of frameworks/APIs/specs to learn just to get one single thing done. The good news for me is that SpringSource has finally caught the hint-I don't have to know the raw details before I use it- and hopefully they are on the right track.The real trick is the container does the plumbing and I do my bizlogic. The current offers by SpringSource as of release 2.5 are on the right track(IMO), but what is lacking is a managed host container- an appserver/container for hosting managed services that a managed bean subscribes to at runtime or programmatically. MS got AOP-style development right a long time ago thru COM+, it's all about context and interception. Think of a scenario where JDBC connections,JMS resources,or about any resource to be used in application code can be configured for use by ALL apps running in the container without using local XML descriptors for each app or at worst minimal declarative resource acquisition thru DI via annonations.And this can even be done from a management console-u should be able manage services used by a deployed bean thru a console! The only dependency would be on the service client libraries referenced in the calling code-which can either be 1.auto-generated( by the container) JARs containing service interface definitions and the necessary proxy/stub pairs 2.auto-generated( by the container) WSDL files that can be run thru a tool to generate the necessary proxy/stub pairs 3. Or even better- a service-invocation framework(can't elaborate on this now) All this if u have'nt guessed it requires a managed framework or a managed container not a suite of over-engineered specs that only looks good on paper. PS: If u have'nt realised it, MS has done it again-LINQ.It's called "ORM for the real world". Long live entity beans and JPA!
  84. Re: ReallyusefulNewFeatures.jee[ Go to top ]

    Agree! But generally you are better paid using over-engineered technology. dotNET consultants are still paid a lower rate than their JEE counterparts in Australia, as far as I can see, even in large mission critical projects, e.g. one of the largest projects in the country in the largest bank of the country.