Home

News: GlassFish v3 and Java EE 6 Released

  1. GlassFish v3 and Java EE 6 Released (126 messages)

    Sun has released the Java Platform Enterprise Edition 6 and the GlassFish Enterprise Server v3. Java EE 6 includes new specifications that add new functionality to the platform, like dependency injection, Bean Valiation and RESTful services, as well as improvements to the existing specifications including very significant improvements to Java Server Faces, Enterprise Java Beans, JPA, Servlets and Java Connectors. Java EE 6 also includes a Web Profile. Additional information on Java EE 6 is available from the WebSite and this Overview Article. The GlassFish v3 Server implements the Java EE 6 specification. GlassFish v3 is Open Source and fully modular, built on an OSGi kernel and the Grizzly NIO infrastructure. GlassFish v3 is suitable for a wide range of applications, from development to deployments. The long list of additional GFv3 features includes embeddability, very fast startup, redeploy-on-save, session state persistence, dynamic language support, management and monitoring facilities, graphical, CLI and REST command interfaces, and an update center. GlassFish v3 is supported by NetBeans, Eclipse and IntelliJ IDEA. Additional information on GlassFish v3 Server is available from the Product Page and our main Team Announcement. GFv3 can be downloaded here; the full version is 70MB and the Web Profile 50MB.

    Threaded Messages (126)

  2. Congrats Sun. With whatever has happened to you in last 2 -3 years in terms of economy, loss of revenue( you had too many managers), merger(or acquisition ?) with oracle - you still came up with this. So thanks and congrats. Although i like spring a lot for what they did before SUN put new features in java, i would like to know from TSS community - would you switch to JEE dependency injection or still be with your own like spring or juice etc. Another question - why the love with EJB ? First we had monolithinc big fat EJBs, then we came up with local EJBs and now EJB lite. Can we just drop it ? we have better transaction managament with JTA, JDO or framework like spring and plus so many remote operations are now done with web services - So do we really need EJB still ? just asking.... Thanks and here is hoping that oracle wont mess it up !!!
  3. no[ Go to top ]

    ... i would like to know from TSS community - would you switch to JEE dependency injection or still be with your own like spring or juice etc.... Another question - why the love with EJB ? ... So do we really need EJB still ?
    No, no clue, no. In short, JEE6 is a compromise between big app server vendors about how the stuff that they sell to us inter-operates. Smart people have migrated to more lightweight solutions that involves not depending on whatever it is big app server vendors actually provide (which is 90% certification and consulting vs. 10% functionality, at best). In short, don't expect to find anything shockingly disruptive in JEE6 that is not already provided in e.g. Spring. At best it will be similar but subtly different (i.e. a potential problem should you choose to switch). So, there are a few useful things in JEE6, but nothing dramatic or shockingly new. If you needed it, you have probably already been using some alternative implementation for years. I would advise to stick with whatever works for you and not worry too much about what IBM, Sun, and Oracle would prefer you to use. Eventually, whatever you use will either catch up or become legacy technology. Especially stuff like Spring doesn't look like it is becoming legacy anytime soon so if you use that, forget about JEE 6.
  4. Re:[ Go to top ]

    Smart people have migrated to more lightweight solutions that involves not depending on whatever it is big app server vendors actually provide
    Dumb people have been a victim of a clever startup company that convinced them that their over-hyped libraries on to of the Servlet API are a replacement for a full-fledged middleware specification and implementation. Now that the indicated company is gone (sold) we will hopefully see less of their victims in the future.
  5. Re:[ Go to top ]

    Smart people have migrated to more lightweight solutions that involves not depending on whatever it is big app server vendors actually provide


    Dumb people have been a victim of a clever startup company that convinced them that their over-hyped libraries on to of the Servlet API are a replacement for a full-fledged middleware specification and implementation. Now that the indicated company is gone (sold) we will hopefully see less of their victims in the future.
    +1 very good choice of words, "Casual Visitor". Today, I just proposed EJB 3.1, JSF, JPA and CDI stack and Intellij Idea also to a company. Hopefully they'll go that way.
  6. Re:[ Go to top ]

    Smart people have migrated to more lightweight solutions that involves not depending on whatever it is big app server vendors actually provide


    Dumb people have been a victim of a clever startup company that convinced them that their over-hyped libraries on to of the Servlet API are a replacement for a full-fledged middleware specification and implementation. Now that the indicated company is gone (sold) we will hopefully see less of their victims in the future.

    +1 very good choice of words, "Casual Visitor".
    Today, I just proposed EJB 3.1, JSF, JPA and CDI stack and Intellij Idea also to a company. Hopefully they'll go that way.
    hopefully they say no to JSF. :)
  7. JSF 2[ Go to top ]

    Hope they give JSF 2 a chance. There are lots of improvements over 1.x
  8. Re:[ Go to top ]

    hopefully they say no to JSF. :)
    Hopefully for them not. In their best interest I hope they say yes to JSF. JSF 2.0 has improved so much over 1.2, which already has very broad support in the industry, that it would be a shame to pass it on just because of some silly FUD being spread.
  9. Re:[ Go to top ]

    Smart people have migrated to more lightweight solutions that involves not depending on whatever it is big app server vendors actually provide

    Dumb people have been a victim of a clever startup company that convinced them that their over-hyped libraries on to of the Servlet API are a replacement for a full-fledged middleware specification and implementation. Now that the indicated company is gone (sold) we will hopefully see less of their victims in the future.
    Great big +1 to this comment.
  10. Re:[ Go to top ]

    Smart people have migrated to more lightweight solutions that involves not depending on whatever it is big app server vendors actually provide


    Dumb people have been a victim of a clever startup company that convinced them that their over-hyped libraries on to of the Servlet API are a replacement for a full-fledged middleware specification and implementation. Now that the indicated company is gone (sold) we will hopefully see less of their victims in the future.
    Casual Visitor, try spring/stripes/rife. rife doesn't use jsp, yet RoR founder - told thats the way to go for java(not JSF). RIFE is a mix of component orientation and request orientation. You will never be disappointed. -casual vistor2.
  11. Re:[ Go to top ]

    say no to : jsf, wicket etc.- all of whom are still wandering in myriads of web development- utterly confused, with no way of solving web development experience. stick to RIFE. Absolutely no marketing in there. Not even a single user at theserverside.com - told rife is bad - http://www.theserverside.com/news/thread.tss?thread_id=41574 I often wonder- JSR spec people - do they have basic graduation?.. Why are hackers, put in to lead JSR?.
  12. Re:[ Go to top ]

    I often wonder- JSR spec people - do they have basic graduation?
    I often wonder - the duplicate marketing post author with shoddy grammar - does he have basic graduation? LOL.
  13. Re: no[ Go to top ]

    In short, JEE6 is a compromise between big app server vendors about how the stuff that they sell to us inter-operates
    Stuff from big app server vendors? You mean Geronimo from Apache? Jboss AS from Redhat? Glassfish from Sun? JoNAS from OW2? Sell to us? Never payed a dime to any of those parties above... I just go to a download page, click a link, and a few minutes later I can use the software in whatever way I like, for free. Oh, and I can make changes to the source too and even distribute those changes (open source). It seems my friend, you're still hypnotized by the [...] words of Rod. You know the guy who wants you to believe EJB2 is still the latest version and IBM is the only one offering an implementation. Incidentally, this happens to be the same guy who wants to SELL you some Tomcat based server with some XML infested Java EE clone on top of it. Talking about hypocrisy... Message was edited by: Jvaughan
  14. Re: no[ Go to top ]

    It seems my friend, you're still hypnotized by the [...] words of Rod.
    Hear, hear. There is plenty in Java EE 6 that is simply not in Spring. The excellent features in CDI are just a start not to mention JSF 2, JPA 2, JAX-RS, bean validation and yes, EJB 3.1. And because it is an integrated platform that doesn't take the Frankenstein model to development, it is much less configuration/XML heavy. Just look at the fact that JSR 330 is a small subset of JSR 330 and that Spring will inevitably be doing catch-up past Spring 3.0 - just as they did for Java EE 5 in Spring 2.5... As to app servers being heavyweight, that's exactly what Java EE 6 profiles are designed to address. In fact, The Java EE 6 Web Profile is the only one Resin is going to implement. Cheers, Reza ================= Author, EJB 3 in Action Expert group member, Java EE 6 and EJB 3.1 Resin EJB 3.1 Lite Container Developer
  15. Re: no[ Go to top ]

    It seems my friend, you're still hypnotized by the [...] words of Rod.


    Hear, hear. There is plenty in Java EE 6 that is simply not in Spring. The excellent features in CDI are just a start not to mention JSF 2, JPA 2, JAX-RS, bean validation and yes, EJB 3.1. And because it is an integrated platform that doesn't take the Frankenstein model to development, it is much less configuration/XML heavy. ... Cheers,
    Reza
    =================
    Author, EJB 3 in Action
    Expert group member, Java EE 6 and EJB 3.1
    Resin EJB 3.1 Lite Container Developer
    Ahh, very nice Reza, what a calculated (and dishonest) way to frame this... As a Java EE expert, and self-proclaimed Spring expert, you know very well that Java EE is an umbrella specification containing many different APIs, and Spring in no way tries to compete with the vast majority of these APIs, works with or builds on top of these APIS and tries to add value to their use, while offering a bunch of other functionality as well. JSF 2, JPA 2, JAX-RS, bean validation (in Spring 3), and many many other Java EE apis, including even EJB, are all usable with Spring. There _is_ no "Spring vs. Java EE". They are not mutually exclusive. It certainly serves the purpose of people pushing a pure Java EE solution to put it that way, but the responsible architect and developer will frame this as, "what is my ROI and other pros/cons if I build my app to pure Java EE, vs the same when targeting Spring+various Java EE (and other) APIs?" And please stop going on about XML in Spring. It's been very easy for more than 2 years to build Spring-based apps with almost no XML, if you want to. Spring 3 continues and enhances things in this regard. Regards, Colin
  16. Re: no[ Go to top ]

    There _is_ no "Spring vs. Java EE".
    Interesting perspective. Then precisely what is SpringSource dm server? It's not a (non-standard) competitor to Java EE?
    very nice Reza, what a calculated (and dishonest) way to frame this...
    Rrrm, you were being just a tad disingenuous yourself, perhaps? Am I being unfair?
  17. Re: no[ Go to top ]

    Colin, Hmmm...I see you've decided to escalate the fruitless personal attacks further. How disappointing but not surprising given the typical pattern of behavior you guys have when faced with even minor criticism... I never said it's "Spring vs. Java EE". By all means, people should be thinking about integrating the two. I have always been a big supporter of that. Take a look at the first/last chapter in my book and my recent JBossWorld presentation: http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf. Indeed I hope to get some Spring APIs adapted to become CDI portable extensions... *All* I have done so far is answer questions about what Java EE 6 offers that Spring currently does not... Building Spring apps with 2.5 is an impossible task without XML, period. Now, it's true things have gotten better since 2.5 but the reality is that Spring will always be harder to configure because it is a framework and not an integrated platform. That's just fact, nothing subjective about it... Peace, Reza
  18. Spring and Java EE[ Go to top ]

    The Spring Framework supports, uses and complements itself many APIs and frameworks that are central parts of JavaEE specification e.g. JSF, JPA, Servlet API, JPS, the Web Container itself, .... To argue that Spring is an alternative to Java EE therefore is - i am sorry to say - simply wrong. EJB spec is just a part of the whole Java EE Spec. The argument that modern Java EE Servers are heavy weight is also just simply wrong. Just take a look at JBOSS or the OSGI based glassfish V3. On the other hands look at the tons of jars that you have to put together for even very simple Spring application using DI and Proxies for AOP. I wonder which of theese should be called heavy weight. On the other hand Spring made dependency injection a wide spread design approach, which is a very good approach and will change our application designs over years. Now it is time to standardize this. And this is the role of the Java community process. Of course it is not in the interest of SpringSource to loose their outstanding role in the community, SpringSource nowadays is a very commercial oriented company. Would you like to get dependend on them? SpringSource by the way is taking part in the Java Community process and has always its chance to bring their ideas into the standard.
  19. Re: Spring and Java EE[ Go to top ]

    SpringSource by the way is taking part in the Java Community process and has always its chance to bring their ideas into the standard.
    Unfortunately, SpringSources "taking part in the JCP" can (as far as I can see) summarized as: 1) Hyping about opening up the JCP 2) Participating and voting on one shadow-JSR 3) Not-voting on everything else.
  20. Re: Spring and Java EE[ Go to top ]

    I feel Java EE6 is a great step. JSF2 is really cool and solves many of the old problems of JSF1. JSF 2 Component creation, Bookmarkable URL and Facelets integration are among my favorites. With Seam it makes a powerful combination.
  21. Yes[ Go to top ]

    Can we just drop it ? we have better transaction managament with JTA, JDO or framework like spring and plus so many remote operations are now done with web services - So do we really need EJB still ?
    Yes, of course we need EJB. They are a perfectly valid and elegant solution, with a low mental complexity overhead that take away the pain of managing transactions or the entity manager lifecycle yourself. And should the need arise, it's completely trivial to call them from a remote location. An EJB is basically a POJO with very convenient defaults for transactional behavior. With EJB 3.1, you don't have to define a local interface and can place the enterprise bean directly in the web archive.This may be an advantage for some, although personally I think it's a good practice to define an interface anyway. Nobody in his right mind would declare all his variables and method parameters as ArrayList. Instead, the interface List is used (code to interface, not to class). For me personally the asynchronous methods are much more interesting and a very welcome addition to EJB. In response to your remark that JTA is 'better'; don't forget that EJBs USE JTA. They simply do it in a transparent way. You can still use JTA manually, but for the majority of the use cases the managed EJB way is easier.
  22. So do we really need EJB still?
    Shawn, You should give my CDI series a read: http://www.theserverside.com/tt/articles/article.tss?l=DependencyInjectioninJavaEE6. That answers the question you are posing. Hope it helps, Reza =========================== Author, EJB 3 in Action Expert group member, Java EE 6 and EJB 3.1 Resin EJB 3.1 Lite Container Developer

  23. You should give my CDI series a read: http://www.theserverside.com/tt/articles/article.tss?l=DependencyInjectioninJavaEE6. That answers the question you are posing.
    Please, take a look to the Spring developer Manual and how a dependency injection framework must be implemented: http://static.springsource.org/spring/docs/2.5.x/reference/beans.html Please, tell me which are the advantages of CDI over Spring IoC; I cannot see any advantage. Bye.
  24. Spring2.5 reference (better post Spring 3 reference ;-))? IMO Dependency Injection must be typesafe (afaik Spring 2.5 is string-based). CDI in JEE6 is typesafe out-of-the-box (ok Spring 3 is type-safe as well, correct me if i'm wrong). In General. You get with JEE6 a full-fledged stack for enterprise applications. If you don't need Services like Security, Transactions, etc. just use plain beans (no EJBs) and use CDI for dependency injection. If you need the such special services annotate your bean and use it as an EJB (without adding additional jars). With JEE6 you get a webprofile so why do you want to use only a Tomcat with thousand of jar's in it. In JEE6 you get a well harmonized package of jar's which interact properly. BTW AFAIK JSR299 was earlier released than JSR330 so probably there are some ideas of JSR299 inside JSR330. IMO that's a never ending discussion. So the best technology is the technology which you are familiar with. At the end of the day software development is not an end in itself. It should support your customer within his daily business and he doesn't care which technology you have used.
  25. Please, tell me which are the advantages of CDI over Spring IoC; I cannot see any advantage.
    I'm not sure about CDI, but in Seam 2.x a request-scoped bean can be injected into a session-scoped bean. Not sure if CDI has this feature either. Can Spring do that (I haven't checked either)?
  26. Please, tell me which are the advantages of CDI over Spring IoC; I cannot see any advantage.
    With all due respect, I am well aware of what Spring provides. CDI provides what Spring provides plus type safety, very robust context management, real stereotypes, clean interceptors, decorators, producers/disposers, an extensibility API, well-defined integration points with Java EE and many more. As I said, give my article a read and see for yourself. Clearly you have not taken a close look at CDI yet... Cheers, Reza
  27. Reza, With all due respect, you are only really aware of what Spring 2.0 provided back at the time in 2006. Type-safe autowiring (including a rich qualifier model), stereotype annotations (including a default scope, transaction settings etc defined on a stereotype), actually clean interceptors in the form of aspects, extensible scope context management, a powerful and well-established framework SPI, and clean integration with Java EE 5 and now even Java EE 6 already... That's all very much dear to the heart of Spring 2.5 and in particular Spring 3.0 as well - in most cases, for more than two years already. Clearly your assumptions are stuck in the past, my friend. Cheers, Juergen
  28. Juergen, I am not sure there is a point to further examining your assumptions about what I do and do not know past that I've implemented 10+ successful Spring 2.5 projects already. Those particular comments seem more geared towards personal hostility/ more than anything else and that's a shame... It's just about as ridiculous as my claiming you don't know Java EE 5 or Java EE 6... However, since you brought it up, I'll answer your specific concerns: * Spring type-safety: Anything that solely depends on names for dependency resolution is not type safe. The typical Spring XML configuration () and autowiring by name are prime examples of this. CDI never relies on just names for dependency resolution. the type-safe resolution in the spec outlines this: http://jcp.org/aboutJava/communityprocess/final/jsr299/index.html. * Stereotypes: CDI stereotypes allow developers to easily group together component meta-data, including interceptors, scope, naming, etc. Spring stereotypes merely allow you to expand component registration beyond the built-in stereotypes (@Repository, @Service, etc) and @Component: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/ch03s10.html#beans-stereotype-annotations. Adding any additional metadata or behavior is impossible without hand-writing container extensions. * Interceptors vs. Aspects: There isn't even a contest here as to what is easier to learn/use. If you believe it necessary, I'll be happy to post code showing why this is the case. * Scopes/contexts: Spring core has no built-in concept of conversations and Spring scopes are not resolved via runtime proxy and hence much less useful in stateful context management as I see it. And Spring scopes are not passivation capable. * SPI: Here is the CDI SPI Javadoc: http://docs.jboss.org/cdi/api/1.0/javax/enterprise/inject/spi/package-summary.html. The SPI is similarly well-described in the spec. Can you point me to a similar resource for Spring? The Spring documentation certainly is of little help: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/. * Integration with Java EE: CDI is an integral part of the platform and hence is unquestionably better integrated. How CDI integrates with every part of the platform including JSF 2, EJB 3.1 and JPA 2 is well-defined down to the component contract level and requires *zero* configuration. Spring 3.0 also has no current support for JPA 2, JSF 2, beans validation, etc. In fact I don't think you have any support for the functionality added in Java EE 6 as of yet. I'm going to bet all this is stuff you will be working on shortly... Peace, Reza
  29. Reza, Sorry for the late reply but I had to get Spring 3.0 GA out the door: http://blog.springsource.com/2009/12/16/spring-framework-3-0-goes-ga/ Now, your points essentially prove that you haven't checked out Spring 3.0 *at all* beyond maybe skipping through the documentation for less than five minutes. And you are using Spring 2.5 like it was Spring 2.0 still. * Spring had type-safe injection with @Autowired and @Qualifier since 2.5. How could you even try to compare CDI's model to Spring's XML bean definitions (and autowiring by name), instead of to Spring's @Autowired model? Even better, Spring 3.0 comes with full JSR-330 support since RC1. How could you not notice when feeling positioned to make public claims about Spring? * Stereotypes in Spring 3.0 support default scope annotations, default transaction annotations, default qualifiers, etc. It may not be documented very clearly yet but I have been pointing this out on the blog several times, even giving common examples. It's a great feature that CDI also has in a similar (but not quite identical) fashion. * Spring scopes can of course have a proxy: The scoped-proxy feature is in there since Spring 2.0 (!), actually. We just leave it as a configurable choice to users whether they want proxies or not, even on a per-bean basis. Admittedly we haven't started on a first-class conversation scope yet; this is on the roadmap for Spring 3.1. I've been mentioning conversation management as the central topic for Spring 3.1 often enough already. For the time being, there are of course Spring conversation extensions that work just fine, such as MyFaces Orchestra. * Spring has specific SPIs for each subsystem. See BeanPostProcessor in the beans module, for example, or ScopeMetadataResolver and ApplicationEventMulticaster in the context module. Spring does not aim to be one big piece with one big SPI, but rather several cooperating modules with individual SPIs. We are even using those SPIs between our own modules, eating our own dog food. * How could you possibly claim that Spring 3.0 has no current support for JPA 2, JSF 2, beans validation? When we effectively had all of this for several months already and in particular in the 3.0 release candidates? We've been following those specs since their inception. I've also been pointing this out every time I talk about Spring 3. * With respect to XML configuration: Try building an EE 5 or even EE 6 app without the use of *any* XML. Good luck with JPA and CDI, both of which require XML deployment descriptors - minimal ones possibly but that's not much different from Spring when using the context namespace and component scanning. And since Spring 3.0, we are even shipping the configuration class model (as known from Spring JavaConfig) and a convenient AnnotationConfigApplicationContext class for bootstrapping with even less or no XML. Reza, all in all, you clearly know next to nothing about Spring 3.0, and by far not enough about Spring 2.5 even. My claim wasn't ridiculous at all. Juergen P.S.: Oh BTW, if you haven't noticed the irony in the wording of my previous post, then please re-read it next to your own post that I replied to.
  30. Juergen, At best you've validated exactly what I said and at worst you are distorting what I said. I'll clarify yet again: * Yes, I am well aware of @Autowired/@Qualifier (see my JBossWorld presentation code), but you missed my point (perhaps deliberately). The point is that Spring XML config is what is forwarded in your documentation and that is not type safe (even for the 3.0 docs!). Hence that is what is used in most applications. No such possibility exists in CDI since injection is firmly type-based as per the spec. * Your claim of Spring Stereotypes is very interesting (I happen to have this is my JBossWorld presentation too). Can you point to a working step-by-step example that mirrors what is in CDI? I want an example where I can define a new component annotation and attach aspects and scope to it purely declaratively and as an integral step in defining the stereotype. * You're essentially validating what I said about Spring scopes, so thanks for that. Spring scopes are not automatically proxied so cannot really be used for reliable context management unless you do additional work. I know that personally because I had to debug the problem in a production environment. I'll be happy to elaborate if you need me to. * You've proven my point on the SPI issue as well. I am well aware of the limited and fragmented SPI that Spring provides. The point is that it is nowhere near as well-thought out as CDI and is merely a by-product of accidental/evolutionary development. Even a casual look at CDI SPI features make that amply clear. As I said, kindly post links to documented features that match the CDI API and I'll be happy to point out the short-comings. * You've proven my point on catching up to the Java EE 6 platform. What you have are *plans* and work in progress. Can you show me a published road-map beyond your saying that "you've talked about it" and "it's in your code-base"? And no, I don't bother checking what you have written to the repository everyday. I've got better things to do in life. I check your docs because that is indication to me that things are ready for prime-time. 6. The bit about Java EE being as XML heavy as Spring is pure bunk. If you want to pursue this further, I'll be happy to provide concrete examples showing how much more complex Spring configuration is. And I've looked at the Java config efforts in 3.0. Using that is even more verbose than XML so I seriously doubt very many applications will go that route or gain very much in terms of reducing configuration complexity. However you slice it and dice it, short of creating the bridge that I already mentioned, Spring just does much less in terms of default configuration than Java EE does. And even that effort is just an after-thought. All your documented examples use XML and hence that's what a majority of applications will use. And no, I don't track your daily code check-ins or sniff your internal network traffic. I never claimed to be a "Spring expert", ever and either is this something I care to pursue. In fact, I am not even sure why this is relevant? Why so hung up on that? The point is that I make an effort to know Spring the best that pretty much any other reasonable developer outside of SpringSource can. Need me to get one of your certifications so I can be "officially qualified"? I'll be happy to oblige just to avoid this inane discussion that's just a waste of time. Let's kindly keep things technical and stay away from personal attacks. I don't do it and expect the same of anyone I respect as a professional. Cheers, Reza
  31. Reza, Claiming that Spring isn't type-safe because we are still also showing XML examples with bean names in the documentation... Come on. If that's your best counter-argument, then we really did a good job. @Autowired has been discussed and shown so much that it almost hurts. FWIW, the JSF 2.0 specification shows the XML managed-bean style very prominently as well, and doesn't even mention CDI... So JSF 2.0 is not type-safe either according to your line of argumentation? Check out the Spring 3.0 GA release which is much more than just "in the codebase". The 3.0 release candidates over the past couple of months were public and well-received, so also much more than just "in the codebase" or "talked about". The RCs may have been a work in progress, but so was Java EE 6 up until last week! And to make it double-clear: Spring 3.0 is *GA* and contains the Java EE 6 support that I listed. Just plans and work in progress? You can't be serious. Of course Spring differs from CDI in configuration style and in particular in defaulting, but so does JSF with its native managed beans (which do not get proxied either). Also, defaults are easy to switch: Spring's scoped proxy mode, for example, can easily be activated in a custom scope stereotype or in the central component-scan configuration. Once per application only, without having to repeat yourself. Very similar to persistence.xml settings in JPA which nobody seems to have a problem with. Now, I won't be playing this game any further. You may choose to misrepresent things but I have nothing to add; I said everything that needed to be said in terms of the facts in my previous post. Cheers, and happy new year. Juergen
  32. Juergen, Good. We can put this sordid discussion to bed and pursue things that matter a little more than "wining" a flame war. I am also glad you've come the realization that it's not your place to "police" what someone can and cannot say. Peace, Reza P.S.: 1. Yes, I do consider CDI to be far more type safe than JSF 2.0 beans and EJB 3.1 style injection. 2. Happy New Year to you as well.
  33. Now, your points essentially prove that you haven't checked out Spring 3.0 *at all* beyond maybe skipping through the documentation for less than five minutes. And you are using Spring 2.5 like it was Spring 2.0 still.
    Juergen, I have nothing but respect for the hard work you guys have poured into this and previous releases of Spring and I know you are a well educated and knowledgeable developer. However, whether your above statement is true or not, I often find the reverse to be true when it concerns knowledge of Java EE. Many times it seems to be assumed by Spring that Java EE is still about EJB2 and that EJB has thus become completely irrelevant. This sentiment seems to be picked up by the Spring fan base, and this then provokes the dreaded reactions from those people in Java EE articles and announcements. Some of those reactions might be simply trolls, but some of these might be genuine utterances of surprise: "Huh, another EJB release? But Rod told us EJB was a sure thing of the past!?" Why can't the Spring fan base simply accept that both Spring and Java EE are very good application frameworks? Even if you use Spring, you don't *have* to think that Java EE is completely irrelevant. You don't *have* to fight against the words "container" and "application server". I for instance use Java EE, but that doesn't mean I go out on a crusade against say .NET or RoR, claiming it's totally irrelevant. captcha: immense fact *lol*
  34. Augustientje, First of all, thanks for the kind words!
    I often find the reverse to be true when it concerns knowledge of Java EE. Many times it seems to be assumed by Spring that Java EE is still about EJB2 and that EJB has thus become completely irrelevant. This sentiment seems to be picked up by the Spring fan base, and this then provokes the dreaded reactions from those people in Java EE articles and announcements.
    That may be a historical heritage in the Spring community. However, I personally talked about Java EE 5 and Java EE 6 *a lot* in the past couple of years, in particular to a Spring audience. I'm sure that many of them heard about the content of those new specs from me for the first time, and also about servers supporting those. And I hope that they went away with a good impression of several key specs at least.
    Why can't the Spring fan base simply accept that both Spring and Java EE are very good application frameworks? Even if you use Spring, you don't *have* to think that Java EE is completely irrelevant. You don't *have* to fight against the words "container" and "application server".
    I don't think that anybody who listened to my talks or read my Spring release announcements etc ever got the impression that Java EE was irrelevant. Quite on the contrary, we are making some good use of EE-related specs ourselves and recommend some of them very clearly. We also run regular tests on common application servers and state our support for those; see today's Spring 3.0 release announcement for an example. Juergen
  35. With all due respect, you are only really aware of what Spring 2.0 provided back at the time in 2006. Type-safe autowiring (including a rich qualifier model), stereotype annotations (including a default scope, transaction settings etc defined on a stereotype), actually clean interceptors in the form of aspects, extensible scope context management, a powerful and well-established framework SPI, and clean integration with Java EE 5 and now even Java EE 6 already... That's all very much dear to the heart of Spring 2.5 and in particular Spring 3.0 as well - in most cases, for more than two years already. Clearly your assumptions are stuck in the past, my friend.
    Juergen, if Spring 3 really does have everything that CDI provides (and note that I certainly don't accept that this is true), then why not implement CDI on top of Spring? If what you're saying is true (I don't think it is) then that should be a basically trivial job, right?
  36. Re: GlassFish v3 and Java EE 6 Released[ Go to top ]

    Gavin makes an excellent point in terms of the probable effort in creating a CDI/Java EE 6 "bridging" layer on top of Spring. It is indeed much harder than creating a Java EE 5 "bridging" layer that could essentially consist of meta-data and configuration translation from Java EE 5 to Spring 2.5/3.0. Implementing JSR 330, on the other hand, looks to be pretty easy because of it's more limited scope. That's something else that's been on my mind a while...I think it would give Spring developers a real chance to play around with Java EE to get a feel for the differences and the similarities... Cheers, Reza
  37. Juergen, if Spring 3 really does have everything that CDI provides (and note that I certainly don't accept that this is true), then why not implement CDI on top of Spring? If what you're saying is true (I don't think it is) then that should be a basically trivial job, right?
    Gavin, I have not actually said or implied that Spring 3 has everything that CDI provides. It has not. Not just because of conversation management but also because CDI contains some syntactical sugar variations that we are not particularly fond of. That applies the other way round as well, though: CDI is nowhere near having everything that Spring provides either. Up there I just pointed out to Reza that he was lightheartedly claiming features as CDI differentiators that Spring clearly has as well, and in some cases has had for more than two years already. I did not make any further claims. With respect to implementing CDI on top of Spring: CDI unfortunately isn't just a set of interfaces or conventions; it is rather a very prescriptive definition of a framework and its runtime behavior. It is more or less impossible to implement it on top of an existing framework without radically changing the established inner workings of that underlying framework beyond recognition. In that respect, CDI is very different from the likes of JSR-330 and also JPA, both of which can easily be adapted onto an existing runtime while preserving the latter's established behavior as well. FWIW, Spring clearly differentiates itself through the very Spring-style model that it is offering. Even just the existence of the term "Spring style" says it all really. Spring is not just an injector backend; it is a rich user-level application framework in its own right. Trying to hammer it into the semantic frame of another framework such as CDI would be an exercise that is certainly achievable (when willing to change established key semantics) but ultimately pointless since you'd lose most of the subtle characteristics that made Spring unique and worth using in the first place. Juergen
  38. Juergen, Good. This is probably as good of a consensus as we are going to get on this. What you are characterizing as a "stylistic" difference is more like a "paradigm" difference. As I said in my JBossWorld presentation, Java EE is a platform, Spring is a framework. In that regard, Java EE is more like Rails or .NET, and Spring is more like building an application with C/C++ libraries. Both have their audiences and both are valid perspectives. Cheers, Reza
  39. With respect to implementing CDI on top of Spring: CDI unfortunately isn't just a set of interfaces or conventions; it is rather a very prescriptive definition of a framework and its runtime behavior.
    Correct. The CDI specification nails down all application-visible behavior, and all portable-extension visible behavior. It does not, of course, specify implementation details. That's the essence of achieving portability between implementations. It's also where CDI is quite different from JSR-330.
    CDI is very different from the likes of JSR-330 and also JPA, both of which can easily be adapted onto an existing runtime while preserving the latter's established behavior as well.
    True in the case of the extremely underspecified JSR-330. Not true at all in the case of JPA. *All* the existing ORM implementations needed to do some work deep in their engine in order to be able to implement the semantics of JPA 1. I guess I'm in the unique position of having been involved in writing and implementing both JPA and CDI, so you're pretty much going to have to take my word on the following: it's no more difficult to adapt a pre-existing DI container to CDI than to adapt a pre-existing ORM engine to JPA.
    ultimately pointless since you'd lose most of the subtle characteristics that made Spring unique and worth using in the first place.
    Concrete examples, please? I don't see how it would be "pointless" to give your users the choice of working with the standard if they want to. Why not let them decide?
  40. Gavin,
    CDI is very different from the likes of JSR-330 and also JPA, both of which can easily be adapted onto an existing runtime while preserving the latter's established behavior as well.
    True in the case of the extremely underspecified JSR-330. Not true at all in the case of JPA. *All* the existing ORM implementations needed to do some work deep in their engine in order to be able to implement the semantics of JPA 1.

    I guess I'm in the unique position of having been involved in writing and implementing both JPA and CDI, so you're pretty much going to have to take my word on the following: it's no more difficult to adapt a pre-existing DI container to CDI than to adapt a pre-existing ORM engine to JPA.
    Well, it was still reasonably natural for Hibernate, TopLink and Kodo to expose a JPA personality without *radically* changing the internal workings of the existing framework, and while keeping their own APIs and their non-JPA kernels and bootstrapping approaches as well. Note that all major JPA providers are built on existing ORM engines; nobody felt a need to implement a major JPA provider from scratch. Now, with CDI, it's exactly the opposite: The only CDI providers that we got at the moment are specifically CDI implementations that have been created for this very purpose and are *not* building on an existing DI container. Doesn't that indicate something? Why is *no* existing DI container finding it natural to provide CDI on top, and all interested parties are creating new CDI impls instead? Also, I take your word for the Hibernate and JPA case. However, all you did for CDI was to implement a clean-room RI. You decided to radically rearchitect Seam 3 on top of CDI, rather than to expose CDI on top of the Seam 2 architecture. So you have no experience building a CDI personality on top of an existing DI container at all. You rather need to take my word that your spec is not suitable for that purpose. CDI is effectively meant to be a kernel that everyone extends and builds on *top* of - in sharp contrast to JSR-330, and in sharp constrast to what Spring would consider implementing as one of its personalities. Spring has its own kernel and its own core architecture which is a defining characteristic. Our users love this and demand to take it forward; they would not appreciate a radical rearchitecture.
    I don't see how it would be "pointless" to give your users the choice of working with the standard if they want to. Why not let them decide?
    Well, they have the choice. They can keep using Spring as they know and love it, or they can try to play with Weld if they'd like to give CDI a try. Frankly, we had *no user* asking for CDI support in Spring yet. We rather had users asking us to continue our way and not get distracted. So we do let our users decide: And our users are clearly asking us to carefully evolve Spring's own style. Juergen
  41. Gavin, Personally, I'd rather Spring *not* implement the Java EE 6 Web Profile, to be quite honest. It leaves a wide open gap for someone like us or the JBoss team to simply create a Java EE bridging layer over Spring. Unlike what Juergen says, as far as I can see, creating a *functional* CDI/EJB 3.1 Lite implementation over Spring would be a piece of cake. Admittedly however, creating on that would pass the TCK *would* be difficult because of some of the gaps we've already talked about... You can drag a horse to water, but you can't make it drink. I was also personally hopeful SpringSource would choose to implement the Web Profile at least for it's server offerings, but clearly that is not going to happen, so why waste your breath asking... Cheers, Reza
  42. Reza,
    Unlike what Juergen says, as far as I can see, creating a *functional* CDI/EJB 3.1 Lite implementation over Spring would be a piece of cake. Admittedly however, creating on that would pass the TCK *would* be difficult because of some of the gaps we've already talked about...
    The functional gaps are not much of a problem at all and can easily be closed as of Spring 3.1, if desired. It's the very prescriptive runtime nature of CDI that is the problem here: It would require special CDI-oriented modes of behavior for nearly everything in Spring core, losing a lot of established Spring semantics on the way. This affects not only the treatment that existing user code relies on but in particular interoperability with existing Spring extensions. It is certainly possible to do two entirely different modes of operation here, but what exactly would the point be? The wealth of extended Spring functionality would still not smoothly integrate with the CDI usage model. Frankly, you could just as well use Weld. It is fundamentally not in the interest of our user community to disrupt the Spring world for no reason other than a spec that has yet to become relevant even in the EE umbrella (see those JSF 2.0 discussions), and is nowhere near production environments yet. The accepted common ground is JSR-330 rather, which does ease migration quite a bit already. And once again, most of our users clearly chose Spring because of its native style, and they explicitly want us to spend our time evolving that native style; that's what we are hearing every time. We'd rather keep the established Spring foundation as it is and optionally enrich it with parts of EE 6; that works just fine for our users, even if it doesn't fit your agenda. If you'd like to try creating a "Java EE bridging layer over Spring", feel free to do so. You'll spend plenty of time on a pointless exercise which doesn't have an actual user audience. But if it makes you feel better in the cozy EE-only world that you'd like to live in, then all the power to you. Juergen
  43. Note that all major JPA providers are built on existing ORM engines; nobody felt a need to implement a major JPA provider from scratch.
    Err, I think you're missing the real difference between JPA and CDI here: to implement JPA *from scratch* would take years. To implement CDI from scratch was more like a 3 month project. It's not that nobody felt the need to implement JPA from scratch - it's really that such a job is simply too much work. It's just *much* easier to implement a DI container than an ORM solution.
    The only CDI providers that we got at the moment are specifically CDI implementations that have been created for this very purpose and are *not* building on an existing DI container. Doesn't that indicate something?
    Perhaps it just indicates that CDI is quite easy to implement?
    However, all you did for CDI was to implement a clean-room RI ..... So you have no experience building a CDI personality on top of an existing DI container at all. You rather need to take my word that your spec is not suitable for that purpose.
    The reason we did it this way was because we didn't want to carry around a bunch of legacy baggage. We wanted Weld to be a very lightweight implementation of CDI, so that other vendors could more easily reuse it. An RI *should* be a fairly minimalist implementation of a specification. I simply don't buy your claim that it would be impractical to implement a dependency injection container that supported both CDI APIs and legacy Spring APIs. That's nonsense on stilts, frankly. If it took us 3 months to implement Weld and the CDI TCK from scratch, I bet you guys could get your own kernel up and running in a couple of months, since you would have our TCK to work against.
    CDI is effectively meant to be a kernel that everyone extends and builds on *top* of
    Certainly. It's a backbone for applications and frameworks.
    in sharp contrast to JSR-330, and in sharp constrast to what Spring would consider implementing as one of its personalities.
    Well, that's quite disappointing, frankly.
  44. Gavin,
    I simply don't buy your claim that it would be impractical to implement a dependency injection container that supported both CDI APIs and legacy Spring APIs. That's nonsense on stilts, frankly.
    First of all, the Spring APIs are alive and kicking and are being actively developed. I remember that you called the Seam 2 APIs "legacy" a couple of years ago already - in the light of the oh-so-great-but-not-available-even-now Seam 3. That certainly made Seam users feel comfortable, right? It would be impractical to implement a strict CDI container into Spring because it would disrupt the Spring core beyond recognition - which is in nobody's interest other than yours. Our users would not appreciate that *at all*, which they keep telling us again and again.
    CDI is effectively meant to be a kernel that everyone extends and builds on *top* of
    Certainly. It's a backbone for applications and frameworks.
    Exactly: It's meant as a backbone. It's not meant to be implemented as a personality on top of some existing container. As I said: in sharp contrast to JSR-330 and also to JPA, and in sharp contrast to what Spring could possibly consider implementing. This is easy enough to see.
    Well, that's quite disappointing, frankly.
    Disappointing for whom? For JBoss because it doesn't fit your agenda? It's clearly not disappointing for Spring users at all. Juergen
  45. Re: GlassFish v3 and Java EE 6 Released[ Go to top ]

    ultimately pointless since you'd lose most of the subtle characteristics that made Spring unique and worth using in the first place.


    Concrete examples, please?
    In the absence of a response to my request for concrete examples, I'm going to assume that these "subtle characteristics" are a result of the magical pixie dust you guys sprinkle on all your APIs. They can be detected by experienced Spring developers when they hold hands at midnight during a full moon and chant the words "Expert One-on-One J2EE Design and Development".
  46. I've stumbled at this discussion right now and it had a lot of potential and informational value. But you discuss like little kids at the kinder garden, for f.. sakes! Trying to offend the person you're discussing with, using childish metaphors (like "are a result of the magical pixie dust you guys sprinkle on all your APIs")...


    Grow up. Discuss like a man. Use real arguments, not ridiculous attempts to offend the other side.

  47. Re: JPA[ Go to top ]

    Not true at all in the case of JPA. *All* the existing ORM implementations needed to do some work deep in their engine in order to be able to implement the semantics of JPA 1.
    Good of you to make statements for implementations that you nothing about. DataNucleus didn't make any significant changes at all in its engine to implement the semantics of JPA1. Fact.
  48. Re: JPA[ Go to top ]

    Not true at all in the case of JPA. *All* the existing ORM implementations needed to do some work deep in their engine in order to be able to implement the semantics of JPA 1.

    Good of you to make statements for implementations that you nothing about. DataNucleus didn't make any significant changes at all in its engine to implement the semantics of JPA1. Fact.
    Well, maybe he just meant the changes had to be done DEEP in the engine, but not that those changes necessarily had to be significant? Just guessing...
  49. very robust, real and clean ...[ Go to top ]

    ... very robust context management, real stereotypes, clean interceptors
    Hi Reza, Can you expand on your comments? - How is the context management in CDI more robust? - Is there an advantage over Spring wrt Stereotypes? - What is more clean about CDI interceptors? Thanks, Rob.
  50. Re: very robust, real and clean ...[ Go to top ]

    Rob, Did my last post help a little? Also, note these are things I'll be shortly covering in my CDI article series. If you know Spring well, you will be readily able to see on your own how it compares. For now, I'd prefer to limit the "Java EE vs Spring" flavor of discussion. Frankly, the question "what does Java EE offer that Spring doesn't?" is mostly flame-bait as I see it these days. You notice most of the people that ask this question are really not interested in learning much of anything beyond simply drinking the SpringSource/VMWare CoolAid... Cheers, Reza
  51. As a developer who used J2EE from very early version (1.x) and also used Spring a little bit (about 2 projects), I found that Spring have BIG advantage in OLD J2EE age (J2EE 1.4 and before), it was advanced in that period (or some applications still on J2EE and before platforms). The purpose why Rod create Spring is just replace old EJBs (but using other J2EE APIs/compontes - his book Expert One-on-One Development J2EE Without EJB). But I found that Spring has very little (or no) use in a Java EE 5 and later platform, because Java EE can offer almost all functionality that Spring can do, and in most case it's easy to use than Spring. One big advantage that Spring can offer in Java EE 5 platform is test case, because Java EE 5 has no embedded container yet, (but Java EE 6 does) and Spring can recognize EJB annotations (such as @Stateless, @DataSource, @PersistenceContext) very well and can run EJBs in test cases without any issue. I also have taken a look and played with CDI (Weld) for a while, and found that as a programming model, CDI is much advanced than Spring, especially in developing Web Applications. Spring guys is just unhappy with CDI because if CDI was well implemented then almost no developers will choose Spring in new (web) projects. This is the reason why SpringSource is always try to block Java EE 6 and JSR 299 in JCP. SpringSource is always consider their own business, but don't consider the (the potential new Spring) developers' benefits. But if SpringSoure was lost the developer, then it lost their business. CDI guys in JBoss does much better than SpringSource, they try to develop a good standard/product/programming model for the developers, and even supports all of their competitor's application server (WELD was using in GlassFish which released earlier than JBOSS 6). They try do a win-win - the developers win and finally JBoss wins. Personally I think Spring age is over, as a trend.
  52. Re: GlassFish v3 and Java EE 6 Released[ Go to top ]

    Wayne, Thanks for speaking up, agree with you 100%. Minor point - you can use something like OpenEJB to unit test Java EE 5 applications for almost any app server. Cheers, Reza
  53. It's sad to see that a dying company is the only one able to release an App Server with the new JEE6 specification on time. The reality is that most of us will be lucky if we'll be able to deploy to a JEE6 compliant App Server in production anytime soon. It'll probably take a couple of years before the JEE6 effect will happen. * Redhat w/ JBoss 6 is late as usual (M1? - wtf). * Weblogic JEE6 support? Probably won't be available till later part of 2010. * WebSphere and JEE6 support? Wait another three years or so before IBM releases WebSphere 8. (Just look at how long it took them to release WebSphere 7 w/ fully JEE5 support - not as a feature pack).
  54. George, I can understand your frustration with the commercial vendors, but I think you are painting an overly pessimistic picture. We are on path to getting Resin certified for the Java EE 6 Web Profile by the first quarter of next year. Geronimo has similar plans I believe. The JBoss release includes bean validation and Weld, arguably the two most important changes in Java EE 6. Since JSF 2, JPA 2 and JAX-RS are pluggable (there is no runtime dependency on Servlet 3), you can use them on any app server you like. As you know GlassFish is already out (and I seriously disagree with the assertion that Sun is a "dying" company). As to WebSphere and WebLogic, you can use Weld/Seam for now on them along with JSF 2, JPA 2 and JAX-RS. Hope it helps, Reza
  55. CDI problems[ Go to top ]

    Hi, I just tried to create a small JEE6 application with GlassFish v3 and faced a problem: I created a very simple bean: @Model @ConversationScoped public class UserBean { @NotNull @Size(min=1,message="Must not empty") private String name; @NotNull @Size(min=1,message="Must not empty") private String password; //.. getters and setters omitted } and tried to access it from a facelet, like this: When calling the page, the following error-message is shown: /index.xhtml @13,108 value="#{userBean.name}": Target Unreachable, identifier 'userBean' resolved to null This is very similar to the example from the JSR-299 specification and should work. Do I have to turn CDI on or something? Thanks in advance, Max
  56. CDI: need empty beans.xml[ Go to top ]

    Hi, Did you create an emtpy beans.xml (really empty) in your app? This is needed to trigger CDI usage... See http://in.relation.to/Bloggers/WhyIsBeansxmlRequiredInCDI Ludo
  57. Thanks[ Go to top ]

    You're right, thank you! I just found the rules for CDI bean deployment archives in the specification. Unfortunately NetBeans fails deploying the web-application with a beans.xml in it's WEB-INF folder. The NetBeans guys might have to work on better CDI support.
  58. yup[ Go to top ]

    You're right, thank you! I just found the rules for CDI bean deployment archives in the specification. Unfortunately NetBeans fails deploying the web-application with a beans.xml in it's WEB-INF folder. The NetBeans guys might have to work on better CDI support.
    The tools will take some time to catch up, too...
  59. Re: yup[ Go to top ]

    Well, it was my fault again: The bean has to implement java.io.Serializable. NetBeans just didn't show the error-message provided by GlassFish. Still, I hope for a better tool support for CDI in future releases. I think it is pretty amazing that there is JEE 6 IDE support at all, this short after the finalization of the JEE6 spec.
  60. Re: yup[ Go to top ]

    Well, it was my fault again: The bean has to implement java.io.Serializable. NetBeans just didn't show the error-message provided by GlassFish. Still, I hope for a better tool support for CDI in future releases. I think it is pretty amazing that there is JEE 6 IDE support at all, this short after the finalization of the JEE6 spec.
    And considering that especially CDI has been a moving target that has changed *a lot* since the first drafts.
  61. CDI[ Go to top ]

    You need the @Named annotation as well.
  62. nah[ Go to top ]

    @Model is a @Named stereotype. But the beans.xml is still needed. Watch the log for the Weld boot message.
  63. Solve CDI problem[ Go to top ]

    Do you've got an empty beans.xml inside your WEB-INF directory? You need a beans.xml in your WEB-INF directory. @Model is a Stereotype with @Named and @RequestScoped. So either delete @ConversationScoped and use only @Model or use @Named together with @ConversationScoped. BTW if you want to use @ConversationScoped it's possible that your bean is passivated so you have to implement java.io.Serializable. FYI check your imports. The annotions from JSF and CDI have got the same name. You have to use the javax.inject ones. So long. Use JEE6! Alex
  64. Re: CDI problems[ Go to top ]

    Do you've got an empty beans.xml inside your WEB-INF directory? You need a beans.xml in your WEB-INF directory. @Model is a Stereotype with @Named and @RequestScoped. So either delete @ConversationScoped and use only @Model or use @Named together with @ConversationScoped. BTW if you want to use @ConversationScoped it's possible that your bean is passivated so you have to implement java.io.Serializable. FYI check your imports. The annotions from JSF and CDI have got the same name. You have to use the javax.inject ones. So long. Use JEE6! Alex
  65. Wicket JSR?[ Go to top ]

    When are we going to have the Wicket JSR?
  66. Re: Wicket JSR?[ Go to top ]

    Douglas, Excuse my ignorance on Wicket, but is it really all that critical with JSF 2? Thanks in advance, Reza
  67. Re: Wicket JSR?[ Go to top ]

    Douglas,

    Excuse my ignorance on Wicket, but is it really all that critical with JSF 2?

    Thanks in advance,
    Reza
    Don't get me wrong Reza, JSF 2 is an improvement, but I would love for a high profile individual such as yourself or Gavin to have a look at Wicket to see the goodness that was always there. Some of which JSF seems to be getting up to. The biggest selling point for Wicket over Struts, JSP, JSF, Stripes, and other MVC type web tier technologies is that it allows you to do easy web tier, component based web development with XHTML and plain Java period! No middleman stuff like Velocity, Facelets, special foreign tags, etc. Also, custom component development is ridiculously simple. I'm waiting till my daughter turns five for her to start playing around with it. There is also a nice stack of prebuilt components to play with right out of the box. Pick your flavor of Ajax based implementations or regular. The out of the box native Ajax support is so good that you may not ever need to have Wicket hookup with other third party Ajax libraries to get fancy Ajax support (Which it handles quite nicely too). Don't get me started on deployment. No custom config file to wrestle with. Just your plain old web.xml required with reference to the Wicket Servlet filter. That's it. In short, Wicket just feels so sane and right. The level of productivity you experience, I beg you to at least look at the hello world implementation so that the JCP can be made aware :) I know that the JCP is always looking around for best of breed open source solutions that can be incorporated into the Java EE API set (e.g.Spring DI, Quartz, etc.). I think Wicket is way up there too and deserves some noticing from the establishment. Peace. http://wicket.apache.org/examplehelloworld.html http://wicket.apache.org/introduction.html http://wicket.apache.org/vision.html
  68. Re: Wicket JSR?[ Go to top ]

    Douglas, Got it. As soon as I can, I'll take a look. For one thing, we could build very good Wicket support for Resin if it really makes that much sense...I know Seam already has this. At "worst" maybe JSF can learn more from Wicket... Cheers, Reza
  69. Re: Wicket JSR?[ Go to top ]

    David, FTR, everyone I know who has played with Wicket has good things to say about it, and that's why we've made Wicket support a priority in Weld and Seam3. Weld already supports Wicket: http://docs.jboss.org/weld/reference/1.0.0/en-US/html_single/#d0e5200 http://docs.jboss.org/weld/reference/1.0.0/en-US/html_single/#numberguess-wicket Note that since GlassFish - the subject of this thread - uses Weld as its CDI implementation, Wicket already works just great with CDI in GlassFish :-) Overall, I think Wicket is a great match for CDI and EE 6: http://in.relation.to/Bloggers/HowToStartLearningJavaEE6 However, despite my usual skepticism of XML, I *personally* prefer defining the UI using a declarative, hierarchical language like XML, instead of in Java. But that doesn't mean I don't recognize that doing it in Java also has some advantages.
  70. I've always mentioned that Tapestry is over-engineerd. You can get a feeling about this statement by visiting Howard's blog at http://tapestryjava.blogspot.com/ to find out how he could over-engineer a simple Captcha generation Servlet. Tapestry is a one-man show. And it's dying a painful and slow death. I hope this is the last Tapestry keyword to appear in this discussion. It's no more a player in the Web framework arena. Leave it to dye. Jan
  71. Jan, I agree with the statement on Tapestry. Similarly, I have never been very impressed by any of the action-oriented web frameworks (beyond the early days of Struts). Personally, I find component/event driven frameworks far more natural and a step in the right direction. I think that is what is key to JSF adoption (now I understand that Wicket is component based as well). I've also been very impressed with ASP.NET. As far as I can tell, JSF 2 solves all the problems that I had personally with JSF. I'd really like to hear from one of the JSF 2 EG members what they think of Wicket... Cheers, Reza
  72. I'd really like to hear from one of the JSF 2 EG members what they think of Wicket...
    Ed Burns (JSF Spec Lead) touches on that in this GlassFish Podcast interview : http://blogs.sun.com/glassfishpodcast/entry/episode_040_jsf_2_0
  73. I've always mentioned that Tapestry is over-engineerd. You can get a feeling about this statement by visiting Howard's blog at http://tapestryjava.blogspot.com/ to find out how he could over-engineer a simple Captcha generation Servlet.
    Ever tried to build a JSF component with the same functionality? Have fun...
  74. Tapesty IOC[ Go to top ]

    This whole Tapestry discussion / bashing seems a bit out of context - if I understand correctly, people say they don't want Tapestry to be part of Java EE. Well, I think that is not going to happen anyway (not that I know much about it, though, but I never heard of such ambitions). Then again, while we are at it: How does Tapestry relate to Web Beans / CDI / Weld? To me it seems most of the novelties CDI brings are covered by Tapestry already, e.g. annotation based scope, and annotation based dependency injection through Tapestry IOC. While it might make sense to combine CDI and Wicket, would it even make sense to combine CDI and Tapestry? What new capabilities would CDI add to Tapestry? Looking forward to your replies, Lutz (who likes both Tapestry and Wicket, and will look into JSP-less JSF 2.0 with Facelets)
  75. Re: Tapesty IOC[ Go to top ]

    While it might make sense to combine CDI and Wicket, would it even make sense to combine CDI and Tapestry? What new capabilities would CDI add to Tapestry?
    What we would win is the capability to inject EJBs and managed beans.. as well as all CDI integrations that may be created in the future. Main benefit for me are transactions, JPA support and remote services which we get for free integrating with EJBs. There is a spring integration module available for tapestry, I wish we would have the same for CDI/EJBs. See this thread as well: http://old.nabble.com/JSR-229%2C-JSR-330-and-other-integrations-to26857781.html
  76. Re: Wicket JSR?[ Go to top ]

    Hi there,� 


    you've written:


    ---

    Also, custom component development is ridiculously simple. I'm waiting till my daughter turns five for her to start playing around with it. There is also a nice stack of prebuilt components to play with right out of the box. Pick your flavor of Ajax based implementations or regular.

    The out of the box native Ajax support is so good that you may not ever need to have Wicket hookup with other third party Ajax libraries to get fancy Ajax support (Which it handles quite nicely too).

    ---


    Do you have anything similar to RichFaces or IceFaces in terms of sophistication, skinnability, looking sleek, good and professional right out-of-the-box?

    If no - ask yourself why, if (as you state) creating custom components is that easy?

  77. Re: Wicket JSR?[ Go to top ]

    I agree that we need a standard based on something like wicket, so we can kill this freakish JSF. Its really sad that these JSR dodos didn't wait for a best of breed technologies to develop and standardize those, rather than inventing JSF. Did they not learn anything from the EJB debacle? Do these vendors care at all about developing usable technologies or are they just interested in standardizing crap so they can sell us on proprietary fixes to them. Or in JSF's case, selling us commercially built components because rolling your own, is incredibly painful in JSF. And I keep hearing about how wonderful JSF 2.0 is. If its anything like using JSF with seam, take my advice and use wicket instead.
  78. Re: Wicket JSR?[ Go to top ]

    Eric, I think it would be wise to look at JSF 2 first before posting overly negative things like this that looks like flame-bait. FYI, JSF is a product of the folks that developed Struts, so there is strong community roots in JSF. If JSF is really as "bad" as you are claiming, I don't think it would be the leading web framework that is still growing its market share despite the numerous "vanity" web frameworks that are out there (I'll reserve judgement on Wicket in particular until I can examine it closely myself). If you notice, Douglas put across what he needed to say constructively and by maintaining a pretty high degree of professionalism. How often do you get good results in life by choosing to yell and scream instead of speaking intelligibly (of course assuming that being heard is something you even care about and you are not just interested in getting some attention)? Peace, Reza
  79. Re: Wicket JSR?[ Go to top ]

    I think it would be wise to look at JSF 2 first before posting overly negative things like this that looks like flame-bait. I'm sure I will check it out. Not because I want to but because someone above me will play it safe and choose the "standard" web framework. FYI, JSF is a product of the folks that developed Struts, so there is strong community roots in JSF. Yes, thank god they didn't turn struts into a JSR standard. If JSF is really as "bad" as you are claiming, I don't think it would be the leading web framework that is still growing its market share despite the numerous "vanity" web frameworks that are out there Maybe JSF 2.0 is great but did you ever try to develop a web app using JSF 1.0? It was just about impossible. This JSR process should not invent technologies just to discover they barely work. Its taken almost six years to fix most of the issues. I'm arguing that the JSR process should wait until a great technology comes along and standardize that instead. I vote for Wicket. If you notice, Douglas put across what he needed to say constructively and by maintaining a pretty high degree of professionalism. How often do you get good results in life by choosing to yell and scream instead of speaking intelligibly (of course assuming that being heard is something you even care about and you are not just interested in getting some attention)? Well, maybe Douglas sounds professional he's using wicket instead of JSF. If he was using JSF, he might be screaming like lunatic as well.
  80. Re: Wicket JSR?[ Go to top ]

    Eric, I've used Struts, JSF, Struts 2, Spring MVC and ASP.NET. I am aware of Tapestry and WebWork but have never actually used them. I have not used Wicket. Thus far, I prefer JSF hands down, and not just because it is the standard. As far as I've seen, no one uses a technology just because it is the standard these days unless it also has technological merit. That's firmly a mind-set that was true in the late '90s and early '00s (I mindset I've never supported, just as I don't support the notion that "open source == great" that's prevalent these days). Yes, there were a lot of quirks to deal with while using JSF with JSP, but I made the switch to Facelets pretty early. I certainly only have positive things to say about using JSF with Seam. It would be helpful to know what your exact problems are so that I can actually understand what you are talking about. If I do end up liking Wicket, it won't be because "JSF sucks" but that Wicket is really better is some fundamental regard. My thoughts on Spring is much the same. It's not that "Spring sucks", I just see the platform approach of Java EE as being much better... Thanks in advance for sharing your thoughts... Cheers, Reza
  81. Wicket versus JSF versus Tapestry[ Go to top ]

    The JSF EG actually does try to see what is out there, and Andy Schwartz, one of the Oracle members of the EG, just did an extensive evaluation of the three big server-side-centric component-based web-frameworks in the java-space: Wicket, JSF and Tapestry, so that the EG can learn from the competition in the further development of JSF (that leaves out GWT as being rather client-centric - while we can learn from GWT for the big vision, I don't think we can take a lot of input in the details). The results were pretty clear: the three frameworks are not far from each other - they are pretty equal with regards to functionality - I won't go into details. He said he would write a blog entry about the whole comparison, maybe he can post the link himself. In the end, the discussion about web-frameworks tends to be a religious discussion about what is better: building your component-tree with Java or with some XML-language. JSF is the only one of these 3 frameworks where you can do both, even if the Java-based approach is certainly harder to do than the XML based approach. And, once more (I cannot repeat it too often): the JSF specification is not about specifying a component library, it is about specifying a base for building components (which is by the way working just great in JSF 2, both in Java and template-based). regards, Martin
  82. @Martin
    The JSF EG actually does try to see what is out there, and Andy Schwartz, one of the Oracle members of the EG, just did an extensive evaluation of the three big server-side-centric component-based web-frameworks in the java-space: Wicket, JSF and Tapestry, so that the EG can learn from the competition in the further development of JSF (that leaves out GWT as being rather client-centric - while we can learn from GWT for the big vision, I don't think we can take a lot of input in the details).

    The results were pretty clear: the three frameworks are not far from each other - they are pretty equal with regards to functionality - I won't go into details. He said he would write a blog entry about the whole comparison, maybe he can post the link himself.

    In the end, the discussion about web-frameworks tends to be a religious discussion about what is better: building your component-tree with Java or with some XML-language. JSF is the only one of these 3 frameworks where you can do both, even if the Java-based approach is certainly harder to do than the XML based approach.

    And, once more (I cannot repeat it too often): the JSF specification is not about specifying a component library, it is about specifying a base for building components (which is by the way working just great in JSF 2, both in Java and template-based).

    regards,

    Martin
    With all due respect, I think if the expert group just takes the opinion of only one of its members, i.e. Mr. Andy Schwartz rather than multiple members of the EG looking at the big three frameworks for themselves, different opinions can be formed by each member. Oracle has a heavy bias and investment in JSF, and by extension so might Mr. Andy Schwartz. I don't use Tapestry, but I can tell you that Wicket is definitely a different beast from JSF. Have you personally taken at least 1 hour to look at Wicket to form your own opinions? Same question for Mr. Dan Allen. Peace.
  83. Re: Wicket versus JSF versus Tapestry[ Go to top ]

    Douglas, I'll let the JSF 2 EG guys answer the questions you've posed themselves. Minor comment from me - I think you have a slightly distorted view of how EGs actually work. Most EGs are far from any passive "group think" - most EG members really do bring different perspectives and work hard towards gaining consensus to create good solutions. This is exactly why the process takes a long time by some people's standards. That being said, the perception problem is not your fault. There are plenty of people out there that seem to feel free to bad-mouth the JCP without really knowing much about it (some of these people also have their own strong hidden agendas for doing so) and the EGs themselves can stand to be a little more open (which is the direction things are going)... Cheers, Reza
  84. Re: Wicket versus JSF versus Tapestry[ Go to top ]

    Douglas,

    I'll let the JSF 2 EG guys answer the questions you've posed themselves. Minor comment from me - I think you have a slightly distorted view of how EGs actually work. Most EGs are far from any passive "group think" - most EG members really do bring different perspectives and work hard towards gaining consensus to create good solutions. This is exactly why the process takes a long time by some people's standards.

    That being said, the perception problem is not your fault. There are plenty of people out there that seem to feel free to bad-mouth the JCP without really knowing much about it (some of these people also have their own strong hidden agendas for doing so) and the EGs themselves can stand to be a little more open (which is the direction things are going)...

    Cheers,
    Reza
    Please pardon my EG, JCP ignorance where demonstrated, but I really would like to know the personal opinions of Cay, Martin, and Dan (i.e. real live EG people), since I am so fortunate to be blessed with their actual presence on this forum. Just for the record, I used to be a big JSF evangelist until I actually decided to listen to some of the bad mouthers and their continued rantings about the short comings of JSF and decided to take an hour to see what this Wicket thing was about. I was blown away at the simplicity and elegance of the framework and never looked back since. I agree with you on the hidden agenda bit of most bad mouthers of the JCP - but it's usually easy to figure out the "bad bad mouthers" (i.e. open source zealots or vanity framework peddlers) from the "good bad mouthers" (i.e. developers who are genuinely and justifiably dissatisfied with the software tools they use). Some bad mouthers nevertheless are essential to keeping the JCP and its respective EGs on its toes though. Maybe we can thank them for helping to get us to Java EE 6, EJB 3.1, Weld, JPA 2.0, and (JSF 2.0). I'm hoping to see a JSF 3.0 with Wicket like features though. Peace.
  85. Re: Wicket versus JSF versus Tapestry[ Go to top ]

    Douglas, I agree with you that hyper-criticism of anything standard does serve a positive purpose. And I am thankful for savvy developers like yourself who can see things for what they really are and have an open mind. In fact, I am very lucky to have just such people as (former) customers. Please don't take my comments personally, I'm just trying to make sure you have a chance to understand that things are not quite the way you might be thinking they are. Indeed, I hope you will consider directly contributing to Java EE yourself one day... Cheers, Reza
  86. FWIW, I haven't expressed any formal opinion to the JSF EG on either Wicket or Tapestry. Even if I had, I don't know that my EG mates would blindly follow my lead. The JSF EG is a pretty opinionated bunch. :-) My goal in researching and preparing a talk on JSF, Wicket and Tapestry wasn't to convince the EG that JSF is perfect the way it is. Actually, just the opposite. Wicket and Tapestry offer interesting perspectives on web application development, and I wanted to look at these frameworks specifically because I knew that there would be good lessons to learn that we might apply back to JSF. I did my best to highlight these lessons in my presentation. I hope to feed my findings back into the JSF EG, though I agree that this shouldn't stop other members of the EG from taking a closer look for themselves. Andy
  87. Re: Wicket versus JSF versus Tapestry[ Go to top ]

    Douglas, FWIW, I'm one of several expert group members who has spent time looking at Wicket (and also Tapestry, Struts 2, Grails, and ASP.NET). There are definitely a lot of things I like about Wicket, but I think JSF 2 is a quality spec, so there's really no need to replace it at this point. --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral
  88. Re: Wicket versus JSF versus Tapestry[ Go to top ]

    In the end, the discussion about web-frameworks tends to be a religious discussion about what is better: building your component-tree with Java or with some XML-language. JSF is the only one of these 3 frameworks where you can do both
    Indeed. Maybe it would help if books, (official) tutorials etc would put some more emphasis on the fact that in JSF one can build a UI just as well in plain Java. The majority of people I encounter firmly belief that the tags they see on a JSP/XML page are the very essence of JSF. Of course this is not true, and the tags are more or less just a wrapper around the UI components which make it easy to compose the component-tree via XML. However, one can just as well use the UI components directly in plain Java. But as I said, very few people seem to be aware of this possibility.
    , even if the Java-based approach is certainly harder to do than the XML based approach.
    Maybe there's a job for EG here, to make the programmatic model easier to use? Maybe just a simple standard view handler and an (annotation based) mapping between view ids and java classes providing the component tree for those views, would be a big help. It's not really hard to make something like that yourself, but a lot of people seem to have no idea where to begin with this. As for the difference between building a UI programmatically in Java or declaratively via XML, it's maybe interesting to note that SWT, a traditional-style client side UI toolkit has recently added the ability to define the UI via XML. See http://wiki.eclipse.org/E4/XWT.
  89. Public Issue Tracker[ Go to top ]

    You are free to post a feature request to the JSF specification using the public issue tracker or by submitting your idea to the public forum. The future of the JSF specification is not set in stone. Join us ;)
  90. Maybe JSF 2.0 is great...[ Go to top ]

    Maybe JSF 2.0 is great but did you ever try to develop a web app using JSF 1.0? It was just about impossible. This JSR process should not invent technologies just to discover they barely work. Its taken almost six years to fix most of the issues. I'm arguing that the JSR process should wait until a great technology comes along and standardize that instead. I vote for Wicket.
    I certainly share some of your frustrations with the process that led to JSF 1.0, but for 2.0, the JSF expert group did just what you suggest. They took a technology that works--Facelets--and standardized it. They did the same with a bunch of plumbing that bothered component developers--with those developers on board. Overall, the result is quite good, I think. Not perfect, but let's face it, neither is Wicket. Going forward, it would be good to figure out what, if anything, makes Wicket more developer-friendly than JSF 2.0, and get that goodness into a future version of Java EE. Cheers, Cay
  91. We value your input[ Go to top ]

    Putting the past aside, the JSR-314 (JSF 2) EG sincerely values the community's input. We have and will continue to work hard to incorporate ideas that have been prototyped and accepted as de facto standards in the community. We welcome you to join the JSR-314-OPEN mailinglist, participate in the JSR-314 public forums. You can find links to these resources at the new JSF community home page: www.javaserverfaces.org (the "Root Node" of the JSF ecosystem).
  92. Re: We value your input[ Go to top ]

    Martin/Cay/Dan, Thanks for your thoughts guys - although I am probably more familiar than most developers on web frameworks, the front-end just isn't my true element - I'm firmly and happily a middle-tier/back-end guy :-). Good to hear about the comprehensive comparison of web frameworks. I knew the JSF 2 EG was doing a great job though... Cheers, Reza
  93. Re: Wicket JSR?[ Go to top ]

    Maybe JSF 2.0 is great but did you ever try to develop a web app using JSF 1.0? It was just about impossible. This JSR process should not invent technologies just to discover they barely work. Its taken almost six years to fix most of the issues. I'm arguing that the JSR process should wait until a great technology comes along and standardize that instead. I vote for Wicket.
    I have developed a web app with JSF 1.0, and you are correct: JSF 1.0 was barely usable. JSF 1.0 was developed, essentially in an Ivory Tower, by a group of well-intentioned developers (including myself) who were by and large ex-Struts committers. But JSF 2.0 is an entirely different story, and it was developed exactly as you envison. For JSF 2.0, we essentially standarized the best features of great technologies, such as Facelets, ICEFaces, Ajax4jsf, Seam, JSF Templating, etc. In fact, we have all of the lead developers of those popular, proven technologies that people had been using for years, on the JSF 2.0 Expert Group. We stood on the shoulders of those giants, as it were, and the result, in our opinion, (and that of many others) is quite impressive. See http://www.ibm.com/developerworks/java/library/j-jsf2fu1/index.html and http://davidgearyblog.wordpress.com/2009/12/13/quebec-city-jsf-2-training-trip-report/ for more information. On the JSF 2.0 Expert Group, we know people have been burned by JSF 1.0, and we aim to make ammends by turning JSF 2.0 into the best web framework we can imagine, and in many respects, IMO, we've done just that. Of course, JSF 2.0 is not perfect, and we continue to work hard to make JSF 2.X even simpler and more powerful. We are also listening to any constructive criticism anyone might have about JSF 2.0, and we will continue to make it better in the future. As my fellow EG member, Dan Allen posted earlier, we welcome your feedback and your participation. See www.javaserverfaces.org for more details.
  94. JSF 2 is very impressive.[ Go to top ]

    I have worked on both JSF 1.2 with Faceletes 1.14 and Seam 2.x with JBoss Rich Faces 3.2. I enjoyed the richness ajax4jsf brought. JSF 2.0 is very impressive and its adoption is really growing every day. JBoss Rich Faces 4 is what will be a next big release for me. I feel JSF 2 has lot of future potential. Power to integrate Yahoo toolkit (Majorra Seam), Ice Faces component, Oracle Rich Faces, Jboss Rich Faces etc gives an interesting power to this framework. I feel in coming days JSF 2.x releases should really focus on 1. Standardizing skinning. 2. Make it more light weight (More client side Sandbox approach). 3. Vendors should focus more on animated charts, drill down grids, rich skins. 3. Probable integration with HTML5 (Vector based rendering). 4. Take good patterns from ASP.Net latest releases 5. Create integration points with Java FX, Flex etc. Java Script should learn more from Action Script which is very clean object oriented language. I see real challenge to JSF is not from Tapestory or Wicket or Struts (They will all be soon very behind), but from Vector based rendering web technologies like Flex and Sliverlight. JavaFx could have solved that problem but unfortunately it came with its 1. Own language (not Faceletes like templating language which is ideal for web framework). 2. JavaFx had no real advanced Web components. It should have complemented JSF 2 or any other web framework as an additional compiler or rendering engine. Summary - Java EE6 is a great step in right direction, JSF 2 is very promising and I hope it will keep on improving in coming days.
  95. Re: Wicket JSR?[ Go to top ]

    You've written:

    Maybe JSF 2.0 is great but did you ever try to develop a web app using JSF 1.0? It was just about impossible. This JSR process should not invent technologies just to discover they barely work

    --------

    With all due respect, but this is utter bull..t. If you've tried to use JSF without Facelets you've brought problems yourself as using facelets was being recommended as best approach for years now. And with facelets and proper component library (like Richfaces) you can build some RIA easily.

    Or you can learn to use tools like Richfaces CDK (component dev. kit).

  96. XML based templating language is what is ideal and that is what JSF 2 brought with it and many other good things. Adobe favors it (AIR and Flex), Microsoft adopted it for C# and Sun adopted it for JSF2 and so Oracle, IBM and Jboss do. But still some people will keep on justifying old patterns. JavaEE6 EGs have done a good job!!
  97. The final judgement[ Go to top ]

    Having read every response in this thread, one may be inclined to ask who won the debate. Well, most of the big clients I work for are still on JDK 1.4. So for me all the sexy features being offered in JEE 6 en Spring 3.0 are irrelevant. If I should choose JEE then I'll be forced to hung on to the evil EJB 2 and be extremely sore. With Spring I can go for 2.5 and very happy. Based on this fact, I think Spring is the BIG winner of this debate. The JEE guys are the BIG losers. Back to coding. Jan
  98. Re: The final judgement[ Go to top ]

    Jan, Sorry to hear that you're still on JDK 1.4! ;-) As you noted, at least Spring 2.5 should get you pretty far - although you'll be missing its Java 5 features even there... Since I suppose your clients are on WebSphere: Maybe you'll see upgrades to WebSphere 6.1 at least; that was the trend that we were seeing in 2009 in particular. WebSphere 6.1 is formally still a J2EE 1.4 server but at least running on Java SE 5, and hence fully supporting the wealth of annotation-based features that Spring 3.0 has to offer. This was a primary reason behind our decision to keep Spring 3.0 compatible with Servlet 2.4 and J2EE 1.4 as the minimum system requirements in the EE area, while being based on Java SE 5 underneath. In the WebLogic world, it's WebLogic 9 that falls into the same category, still being quite common as a production server too. At the same time (getting back to the original topic of this thread!), Spring 3.0 explicitly supports GlassFish v3 which is actually a nice server to run Spring-powered applications on, without any specific configuration needed... exposing Java EE 6 level APIs for use in Spring-based applications... But then again, GlassFish is a bit hard to find out there in the wild still - unfortunately. Juergen
  99. Re: The final judgement[ Go to top ]

    Jan, Ummm...I'm not sure who assigned you to be judge and jury here, but... If J2EE 1.4 and Spring 2.5 works for you, good for you. Don't go imposing your views on others based on your inability to upgrade your app servers - that's hardly true universally. In my client base, I've only seen Java EE use grow and I can honestly say I see more people using EJB now than I ever have in my own career. As I see it, that trend is here to stay and so are we... Cheers, Reza
  100. Re: The final judgement[ Go to top ]

    Reza I also read every single one of these posts, but my goal was not to judge who won or lost the debate simply because there was really no debate. . . There is a lot any one who is remotely familiar with Spring and/or JEE can say in response to your carefully crafted misstatements (eg., spring DI is not type-safe, etc... ), cheap shots (e.g., "XML based DI is what I meant..." etc...) and down-right lies (just re-read Juergen responses). . . And things have been said by many folks here, but it is clear that you have no desire to understand any of them, so I won't even try. What is sad is that at this point in your career besides these dirty tricks that we've seen before, you have nothing more to offer with regards to engaging in a fair and productive technical debate. . . Cheers Oleg
  101. Re: The final judgement[ Go to top ]

    Oleg, How very classy...a total personal attack without even an effort towards technical discussion besides unfounded and self-serving accusations. I'm sure it'll take you great places in your career...and mine is doing just fine, thank you. You won't mind too much if I don't give much weight to the opinion of what SpringSource employees like you think about me... Cheers, Reza P.S.: Happy New Year
  102. Re: The final judgement[ Go to top ]

    Jan,

    Don't go imposing your views on others based on your inability to upgrade your app servers - that's hardly true universally.

    Cheers,
    Reza
    Reza, I'm not imposing my views on others. The judgment I made was for myself and it was based on my own situation. So, don't take it personal. Jan
  103. Re: The final judgement[ Go to top ]

    Jan, Don't worry about it...I talk a tough talk but I'm really a softie :-). I know you didn't really mean it the way it came across... Do keep in mind, however you really feel about Spring or Java EE based on what you think you know, we all work pretty hard at some of this and not always just for the money but because we are engineers, artists and craftsmen that believe in creating something beautiful. That's especially true for the EGs where many people like myself volunteer as independents not affiliated with any company - and many work quietly behind the scenes and are not nearly as vocal as I am :-). At any rate, purposely trying to insult *anyone* never serves a purpose, I think - especially people you barely know. See you around, Reza P.S.: My sincere sympathies in being stuck with such an old JVM. I hope that changes for you soon...
  104. Raza wrote:

    "If J2EE 1.4 and Spring 2.5 works for you, good for you. Don't go imposing your views on others based on your inability to upgrade your app servers"


    That alone disqualified you in my eyes as a reliable source of at least semi-objective information. You've insulted someone, who has different opinion than yours - in childish and ridiculous manner.

    If let's say bank's infrastructure is built upon Java 1.4 and there is no political will in the company to upgrade, provider of a new system (worth 10th of what it would cost to upgrade all running apps to java 1.5) has to adhere to that requirements. 

    I hope I won't have to work people like you ever...

  105. Re: The final judgement[ Go to top ]

    Having read every response in this thread, one may be inclined to ask who won the debate.
    Well, most of the big clients I work for are still on JDK 1.4. ... Based on this fact, I think Spring is the BIG winner of this debate.
    The JEE guys are the BIG losers.
    LOL, or, possibly, folks still using Java 1.4 in 2010 are the "BIG losers". I mean, seriously? Java 1.4??!
  106. Re: The final judgement[ Go to top ]

    LOL, or, possibly, folks still using Java 1.4 in 2010 are the "BIG losers".

    I mean, seriously? Java 1.4??!
    Best comment in this whole debate! :D Whether you use Spring or Java EE/J2EE, if you still have to run it on Java 1.4 this time and day you've already lost. What are you guys btw running this Java 1.4 on? A Linux 1.x kernel based OS, Apple OS 9 or Windows 98?
  107. Re: The final judgement[ Go to top ]


    What are you guys btw running this Java 1.4 on? A Linux 1.x kernel based OS, Apple OS 9 or Windows 98?
    No, we're running it on Windows 95 and we're doing only AWT Java applets. A sarcastic answer to a sarcastic question :-) Jan
  108. Re: The final judgement[ Go to top ]

    LOL, or, possibly, folks still using Java 1.4 in 2010 are the "BIG losers".

    I mean, seriously? Java 1.4??!
    Gavin, I must surprise you with the news that some big financial institutions here in the Netherlands are still running JDK 1.4 in production environment and don't see the need to upgrade yet. Being an external consultant, I can only advise them to upgrade but can't force them to. I'm called in to work on what they have. Or do you want me to reject the contract because they're not on JDK 1.5+? That doesn't seem wise to me because, just like you, I have to pay the bills in the long run :-) Jan
  109. Re: The final judgement[ Go to top ]

    Jan, That's somewhat understandable given how risk averse/stingy companies have become over the past few years (especially financials)...hopefully things will change for you once the economy gets turned around. One way to "sell" the upgrade, of course, would be to tout the benefits in terms of application performance, reliability and developer productivity (hence long term cost savings)... I do have to say you are an exception though, I really haven't come cross any 1.4 systems in at least 2+ years. However, I've always had the luxury of choosing projects (to a degree)... Cheers, Reza
  110. I really haven't come cross any 1.4 systems in at least 2+ years.
    A small company I recently worked at (for a very short period of time) is still using JDK 1.4 with OC4J 10.1.2.0.2 (J2EE 1.3). It's very strange going from a bleeding-edge application stack with JBoss 4.x, Seam 2.x, JSF 1.2, Facelets, JPA 1.0, Hibernate, RichFaces 3.x to JDK 1.4 and no more annotations, varargs or generics support. It's like being handicapped. Add to that mix Struts 1.2 and no AJAX capability and go to jail. It sucks. But it does happen and still does exist in prod systems today.
  111. Re: The final judgement[ Go to top ]

    I must surprise you with the news that some big financial institutions here in the Netherlands are still running JDK 1.4 in production environment
    I'm also based in the Netherlands and doing consultancy work, but mind you, JDK 1.4 IS getting rare. The bigger financial institutions might indeed be the ones lagging behind, but The Netherlands isn't completely filled with "big financial institutions". There are tons and tons of businesses in other categories and those certainly aren't running on JDK 1.4. There are 2 main risks on hanging on an ancient technology for too long: 1. You'll run the risk of alienating your developers. The older the tech, the more developers will walk away and the harder it will be to get replacements. 2. If you haven't found the time, money and will to update in the last year, what chance do you have to upgrade the next year? Of the year after? The longer you wait, the harder it gets to upgrade. In most of my projects I've seen people having an explicit 'fast upgrade' policy. Don't recklessly install the latest version of everything, but continuously try to stay as much up to date as possible. Following this policy, the upgrade work is always done in minor batches and you don't let it pile up to an insurmountable stack. If you have incrementally updated your software base from Java 1.0 onwards to the latest Java 6, the work should always have been doable. On the other hand, if you now would have to update from a pure Java 1.0 code base to Java SE 6/Java EE 6, then the amount of work needed to be done is almost impossible to oversee and would be more like porting your app. You might as well decide to rewrite from scratch in .NET.
  112. Re: The final judgement[ Go to top ]

    Augustientje, That's an excellent analysis. Most US companies I know of have similar upgrade policies as well... Cheers, Reza
  113. Re: The final judgement[ Go to top ]

    Being an external consultant, I can only advise them to upgrade but can't force them to. I'm called in to work on what they have. Or do you want me to reject the contract because they're not on JDK 1.5+? That doesn't seem wise to me because, just like you, I have to pay the bills in the long run :-)
    Jan, money is nice, but personally I would stay far away from projects using Java 1.4. The more time you spend working on these projects, the less time you have for developing your skills in and knowledge of the modern Java ecosystem. Development with Java 5+ is a very different experience. I'm not just talking about the language, but also the frameworks designed for use with with Java 5. And it's a much nicer and much more enjoyable experience. Working with JPA2 is a much better experience than Hibernate 2.x with XML. Working with CDI is a very different experience to Spring with XML. Etc. Plus, Java 1.4 to me is a huge red flag that there are other, deeper organizational problems at work. It's a sign of a dysfunctional project or IT organization. I would just not want to buy into their dysfunction.
  114. Old JVMs[ Go to top ]

    I really feel surprised people still use JDK1.4 (May be they don't have good architects). As an architect or senior technical person one should always influence decision makers to push for latest things. No one will be ready to take risk until and unless changes are sold professionally. I myself convinced 4 years back big production applications to migrate to jdk 1.5. BTW JDK 1.6 has very good Garbabge collection especially on 64 bit environments and many other things endless to mention here.
  115. Re: Old JVMs[ Go to top ]

    Thier was good discussion going on this forum on JavaEE6, people using old JDK should not be allowed to divert the focus :)
  116. Re: The final judgement[ Go to top ]

    I mean, seriously? Java 1.4??!
    I do contract work and do see my fair share of fubar'd projects -- believe me it can be nasty at times. I can fully believe there are loads of projects still stuck on Java 1.4 and I would bet that for many of these projects being stuck on Java 1.4 is just one sign the project is a total mess. Tom
  117. This might be a stupid question but why is so important that Spring implements the web profile? The “Spring vs Java EE” has done wonders for both Spring and Java EE. It’s due to this competition that has made Jave EE 6 something very viable. I think EE 6 will mark the return of many people who defected from the platform.
  118. Serge, To a degree you are correct if you buy the argument that Java EE application server vendors do not compete with each other. I don't think that's really the case. As I see it, SpringSource joining the Java EE ranks would mark a new era for SpringSource, Java EE and enterprise Java as a whole. Instead of fighting each other, we could be working together in many great ways for the benefit of the community. If you will, there is a cold-war parallel here... Most importantly, reducing unnecessary fragmentation would reduce complexity for developers, particularly entry level developers. With the current situation, there is a good chance such developers are getting turned off by enterprise Java - that is a very real long term danger. Cheers, Reza
  119. First off, I'm a Java EE user and advocate, but let's take a slightly different approach at looking at the argument of Java EE x vs Spring x. 1) From an economic point of view, having two competing application server frameworks/platforms in the Enterprise Java space is a good thing. Both competing technologies will ultimately make both of them technically better and stronger over time. This will make for an efficient enterprise Java market where the consumers of these technologies will be able to benefit from technical efficiencies, price efficiencies, and choice. 2) Spring Application Server tech is also a good counter balance to corporate giants like IBM, and Oracle eventually cornering the Java EE market, based on the weight they can bring to bare on competing open source alternatives when they crank up their billion dollar marketing campaign to convince corporate executives that their Java EE products are superior to anything else out there. 3) Creating formal organizations (whether corporate entities or mature non profit organizations) around technologies developed in the "wild" is a good signal to businesses that they can rely on these technologies to run their businesses. Good examples of these are Redhat(Linux, Jboss), Apache (Tomcat, Apache Web Server, etc ...), Sun (Glassfish, etc..), MySQL AB (MySQL, ...), Caucho (Resin, etc.). 4) It is very interesting to have a body/group think about an alternative way in which Java Application Server tech can be implemented, including enterprise Java APIs. I like the idea of competing ideas. I think it's healthy, and in any event, the market will decide the winner no matter the PR and propaganda being banded about by either the Java EE camp or the Spring camp. 5) I also like the idea that the Spring people seem to understand the concept of interoperability in that they have made aspects of their techs, supportive of Java EE. So please let the ideas contend and the passions continue to flow. My only concern of SpringSource and other similar companies, is that they make the prices of their commercially available products and services more public - particularly via displaying these prices on their websites.:-)
  120. Re: Spring is Very Necessary !!![ Go to top ]

    Douglas, There is, of course, a very valid argument here (something I've pointed out repeatedly). To a degree, it's a very tough judgement call as to where things really fall in the competition-fragmentation spectrum, and I don't know that I have the real answer. This is another reason I've come to the conclusion that the final bridging layer between Java EE and Spring should really come from someone other than SpringSource for Spring developers that see the value in the Java EE model as you do. Cheers, Reza
  121. CDI is a big threat to Spring[ Go to top ]

    From my point of view, dependency injection is the most valuable part in Spring. And now, Gavin King made CDI as standard. It's a big threat to Spring. Let's see.
  122. There are a couple of factors here in this very long thread that have not been addressed: 1) incremental hot deployment like in JRebel or Seam 2.x 2) must I upgrade my EE5 app server from, for example, JBoss 4.x to JBoss 6 or Glassfish v3 to start using the EE6 platform's APIs, RIs? What about going from Spring 2.x to Spring 3? Does this apply as well or not? What does Spring 3 offer in terms of hot incremental deployment over-and-above what HotSwap offers? Developing with exploded EAR or WAR with Seam 2.x is great for quick Facelet and JavaBean turnarounds (note: entity classes and EJBs are not supported currently). And Spring being an application stack and framework rather than a platform like EE6 seems to have a distinct advantage in terms of lower barrier-of-entry to Spring 3 from existing Spring 2.x apps, no? If I have an EE5 server (like JBoss 4.x, well that's not 100% TCK EE5 certified so I guess JBoss 5.x which is officially discontinued?), must I upgrade to a EE6 server to start developing and deploying EE6 apps using web profile?? These two items are critical to me and many enterprise Java shops. These are important considerations in selecting a future technology stack. I am a EE6 and Seam supporter but it seems to me that Spring has the advantage with regards to #2 above.
  123. http://wiki.glassfish.java.net/Wiki.jsp?page=V3FullBuildInstructions "You must use JDK 1.6 Update Release 4 or above to build GlassFish v3 and make sure that it's in the PATH." So we must also upgrade from existing JDK 5 to JDK 6 to use EE6 platform implementation? This is not required for Spring 3, it's minimum JDK 5 for Spring 3...
  124. http://wiki.glassfish.java.net/Wiki.jsp?page=V3FullBuildInstructions

    "You must use JDK 1.6 Update Release 4 or above to build GlassFish v3 and make sure that it's in the PATH."

    So we must also upgrade from existing JDK 5 to JDK 6 to use EE6 platform implementation?

    This is not required for Spring 3, it's minimum JDK 5 for Spring 3...
    "You're living in the past, Marge. Stop living in the past." It's already two months that JDK 5 is at the end of it's service life. http://java.sun.com/products/archive/eol.policy.html Upgrade! (Yes....I know....it's not always that simple.) Cheers and Happy New Year. F. Daoud http://www.stripesbook.com
  125. 113 Messages for something that would be widely available in commercial app server maybe in a couple of years. While, I think, 90% of web apps can still be correctly implemented with any good ajax framework (ZK ?) + plain ORM. Ah, OK, some engineering and judge capability is still required. Guido
  126. Guys and girls, Love all the hissy fitting and mud slinging. Very entertaining! It's like watching the Republicans and Democrats debate during elections. My suggestion is to continue this conversation in a public arena. It should be a lot of fun and perhaps we should all just go outside and have a snow ball fight! Congrats to both teams on delivering their impressive platforms. I feel like I'M the winner here and I'm sure many J2EE developers feel the same way. Merry Xmas, Marc
  127. Re: Love all the hissy fitting[ Go to top ]

    +1 : I am just happy that the technology keeps improving and that we have several interesting choices. Just resist the temptation of embarking in these debates unless you think you'll get something useful out of it (a good technical discussion, not a personal-attack-ridden pissing contest), and use what works for you. By the way, you cannot be ironic. You can only be sarcastic. People can be sarcastic; situations are ironic. Sorry but that's a pet peeve of mine ;-) Merry Christmas!