Help

With the release of Java EE 6, I've seen a number of recurring, but rather curious, arguments against upgrading to the new platform. These are usually deployed by folks who are using a homegrown stack consisting of a servlet engine like Tomcat or Jetty together with a number of open source frameworks like Hibernate and Spring.

Now, of course, I'm sure there are plenty of good reasons to choose a non-standard open source technology as an alternative to, or in addition to, a technology included in the EE platform. Happily, you're free to use whatever open source frameworks you like in EE 6 - indeed, Servlet 3 and CDI include a bunch of functionality to make integration of third-party frameworks as seamless as possible. So this doesn't amount to a reason to not use EE 6.

Rather, I've seen people saying the following:

Upgrading the EE application server is hard

This seems to be an organization-specific political problem, rather than an actual technical problem with the application servers themselves. Certainly, upgrading a server like GlassFish or JBoss is usually a pretty trivial task. (And upgrading third-party frameworks is certainly not always painless.) Apparently, some organizations have put in place extremely heavyweight processes surrounding server upgrades, without introducing similar processes for frameworks which run inside the server, thus making it easier for the development team to deploy upgrades to third-party frameworks than to the application server itself.

Well, this sounds to me more like an argument for developing more responsive processes than an argument for abandoning Java EE. There are certainly risks associated with running your application on an old or obsolete server platform, and your processes shouldn't encourage that practice.

But from a practical perspective, almost everyone is going to want to upgrade to Servlet 3 in the near future. This means a server upgrade, whether you're using Tomcat, Jetty, JBoss, GlassFish, Resin, WebLogic, Oracle or WebSphere. This is an excellent opportunity to simultaneously migrate to an EE 6 web profile. A golden opportunity, in fact.

EE application servers are bloated

The objection is that the EE server includes functionality that the team is not (currently) using. Well, then don't use it! Oh.

This argument usually devolves into a discussion of jar sizes, and a comparison of the disk space occupied by the servlet engine and third-party frameworks versus an EE application server deployment. Upfront, there's a couple of things wrong with this argument:

  1. the amount of disk space we're talking about in either case is just tiny when measured in dollars, and
  2. the size of the application war file is actually more important than the size of the server installation, and including more functionality in the server helps reduce the size of the war.

But by far the biggest reason to reject this argument is that the new Java EE 6 web profile is so obviously not bloated. When the first certified web profile servers make it into the market place, we'll have a new just right sweet spot between too big full EE application servers, and too small servlet containers.

J2EE and EJB2 sucked!

The idea here is that we can take revenge on the people who gave us entity beans by refusing to use anything else that has gone through the JCP standardization process. Of course, this is a special form of revenge which involves the user cutting off his own nose. Oh and:

  1. That was eight years ago! Is this really your best shot?
  2. Several great specifications have emerged from the JCP, some of which you almost certainly are using. No, the JCP has not had a 100% success rate - far from it - but then, who has?
  3. Most of the folks who worked on EE 6 hated EJB2 and J2EE just as much (or more) than you did. That's why they joined the JCP - to help fix the problems. For example, the, ahem, author of this blog post was the creator of Hibernate. Are you really trying to give him a lecture on the problems of EJB2?
  4. The folks who invented entity beans have probably all retired by now!

The truth is that the technologies in the Java EE 6 web profile range from very adequate to cool as shit. You're doing yourself and your employer no favors by not trying them out for yourself.

Application server portability is a myth!

Really? Then why do we see so many people porting applications between different application servers? Oh, I see, you mean 100% perfect world zero-changes-to-my-application platonic ideal portability. Well, OK, I understand that the nerd mindset has a weak spot for absolute truths and platonic ideas, but can we take a step back in this case, please?

In which scenario are you really better off, from a portability perspective:

  • 99% of your code, and 85% of your external metadata is compatible between server platforms - and the remaining 1% and 15% can be ported reasonably easily
  • 40% of your code and 80% of your external metadata is tied to a non-standard, single-vendor container architecture

When I make this point, it usually results in an immediate subject change from application server portability is a myth to I don't care about container portability. Well, OK, that's a value judgement that you're entitled to. But your subject-change concedes the point that application server portability is real. And it's useful to many organizations.

UPDATE: I'm still waiting to see a more substantive critique of EE 6 from advocates of alternative technologies. I consider the arguments mentioned above to be non-substantive, in the sense that they don't raise real, technical problems with the usability of the EE platform for application development. The quality of the latest round of specifications seems to have left the anti-EE camp (temporarily?) short on ammunition.

80 comments:
 
08. Jan 2010, 11:07 CET | Link
Drew

There are still a few, real concerns. Mostly involving key non-J2EE6 Frameworks not being J2EE6 compatible. Just in the JBoss world, you have some too. RichFaces, for instance, has their JSF2 compatible version in Beta and not every company who uses RichFaces will be willing to run beta software. Certain portions of Seam aren't handled by JCDI. Most notably webflows, jBPM integration and all of the different templating bits (email, PDF, etc.) I don't think that JCDI Beans can be used as Seam beans natively. Please correct me if I'm wrong (and I would love to be wrong!)

Me personally, will be writing my next project on J2EE because I don't require much of the above. Lack of Webflows would probably be the one that annoys me the most but I know Seam 3 will come about and fill in my need (if it isn't it's own JSR by then or something. ;) )

 
08. Jan 2010, 12:24 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com

First, an introduction:

  • I use Spring (Framework, Security, Integration, WS - in that order)
  • I like JavaEE and I like the direction it's heading

Please take all my opinions not as JavaEE criticism but as some requests for enhancements.

I've been following and participating in (now) famous thread at TSS about Spring 3.0 release and one thought comes to my mind - JavaEE guys are much more fanatic about their product/spec than Spring guys.

It's not a good way of convincing developers/managers that JavaEE is great by bashing all non-standard frameworks and libraries. It doesn't work for me because I know there is neither such thing as Spring vs. JavaEE nor Spring way vs. JavaEE way. I've been through a period in my carrier where I was doing everything to base my code only on javax.* packages. Now I just want to get my job done in clean and maintanable way.

That's why I'm using Hibernate and not JPA. Of course I'm using and am aware of JPA annotations in Hibernate. What's important is that I chose Hibernate and not JPA first. My code will be portable because I carry hibernate JARs with me (in my WAR or seldom EAR). The benefit of JPA is that its specification allows to find people skilled with that technology, but choosing Hibernate in the first place gives me all the non-JPA features Hibernate has. My experience tells me that it's just better to know what's below - just in case you have to submit a bug in implementation or check something in source code.

One more thing about Spring vs. JavaEE (no - I'm not thinking EJB2). I've read the entire JSR299 spec. I like it's strongly-typed, it's @Qualifiers, @Producers, but after reading the spec with existing Spring app in mind I have some questions/observations:

  • How can you wire a filled Map? (configuration or some high-level mapping)
  • Are @Producer methods the only (non-extension) way to return filled Map?
  • Isn't the entire SPI concept just a nice and diplomatic way to hide a fact that CDI is just ... simple DI? Spring's DI container has many concepts of BeanPostprocessors, BeanFactoryPostprocessors, PropertyPlaceholderConfigurers, bean definition inheritance, method injection. Isn't SPI a way to tell If you want it, write/buy/get an extension provider?

You don't have to convince me that CDII is something good and needed in JavaEE - but in real life project I would like to use something more powerfull. When (if) SpringSource releases its CDI extension I'll still write programs with Spring and not CDI in mind just as I use JPA @Entity and @Table annocations but write Hibernate's HQL or Criteria API code.

So Gavin (as most visible JavaEE leader), don't change anything in JavaEE - just make JavaEE 7 better than (good) JavaEE 6. Just don't spread the pure JavaEE or you suck FUD.

I'm sure many people are confused - they think, they have to choose between JavaEE and Spring. Can't you tell them that Spring (and Seam and other libraries/frameworks) just makes JavaEE more ubiquitous? Makes it easier? You're promoting Seam - even if it will be CDI SPI extension it'll still be Seam - you'll have to include it in your WAR/EAR. Just like Spring.

And finally - knowing what's in your WAR/WEB-INF/lib and relying on it it's good thing. I had much more problems with JavaEE container provided libs (from XML, through Servlet-API and EL to EJB) than with my JARs. I can't use my own Servlet-API, but I can use Hibernate in version I like/want.

regards Grzegorz Grzybek

 
08. Jan 2010, 13:17 CET | Link
baz

Our customers use Websphere as application server. And they use version 6.1 :-( We expect that they will upgrade to version 7.x at the end of 2010 So, i do not see an upgrade path to Jee6 in the next 12 month.

On the other hand, i am using jee6 for some little projects to learn this plattform now:-)

 
08. Jan 2010, 13:31 CET | Link

Dear Gavin,

I would really love to develop using Java EE 6 now, but when will my customers be getting a GA release of JBoss 6 ? Because I'm pretty sure that they will not want to deploy on a milestone release.

So your suggestion is ok in theory, but in practice it will take at least two years before customers are EE 6-ready even though the developers will be ready long before then.

 
08. Jan 2010, 13:45 CET | Link
There are still a few, real concerns. Mostly involving key non-J2EE6 Frameworks not being J2EE6 compatible. Just in the JBoss world, you have some too.

Sure. But it's just a matter of time before third-party frameworks are upgraded to run on EE 6.

Our customers use Websphere as application server. And they use version 6.1 :-( We expect that they will upgrade to version 7.x at the end of 2010 So, i do not see an upgrade path to Jee6 in the next 12 month.

But doesn't that really demonstrate the value of choice in the application server market? Your customers do have the choice to use GlassFish (which is available now) or JBoss (which will be available soon). If they choose, for their own masochistic reasons, not to take full advantage of the choices that are available to them, we should be criticizing them, not criticizing Java EE.

I would really love to develop using Java EE 6 now, but when will my customers be getting a GA release of JBoss 6 ? Because I'm pretty sure that they will not want to deploy on a milestone release.

I certainly hope and expect they won't be waiting long. If they are, it's we (JBoss) who deserve the criticism, and people should look for alternatives to our product. Which, fortunately, the market provides.

 
08. Jan 2010, 14:18 CET | Link
one thought comes to my mind - JavaEE guys are much more fanatic about their product/spec than Spring guys.

Hah! I've always thought I was on the pragmatic, non-fanatic side of the debate ;-)

It's not a good way of convincing developers/managers that JavaEE is great by bashing all non-standard frameworks and libraries.

Of course not! Hell, I'm the author of a couple of non-standard frameworks and libraries. And one of the main goals of Seam is to make it easier to use some third-party frameworks in the Java EE environment. But I think it's best for the Java ecosystem if very successful ideas are eventually standardized.

I've read the entire JSR299 spec. I like it's strongly-typed, it's @Qualifiers, @Producers, but after reading the spec with existing Spring app in mind I have some questions/observations:
  • How can you wire a filled Map? (configuration or some high-level mapping)
  • Are @Producer methods the only (non-extension) way to return filled Map?

Um, sure, I suppose so. And how do you do it in Spring? Using XML? How is that possibly better? The code you write in XML is less typesafe, more verbose, less toolable, less refactorable. CDI let's you write that code in Java, and, using @Alternative, have it be deployment-specific, just like your Spring XML is.

  • Isn't the entire SPI concept just a nice and diplomatic way to hide a fact that CDI is just ... simple DI? Spring's DI container has many concepts of BeanPostprocessors, BeanFactoryPostprocessors, PropertyPlaceholderConfigurers, bean definition inheritance, method injection. Isn't SPI a way to tell If you want it, write/buy/get an extension provider?

Well, I guess BeanPostprocessors, BeanFactoryPostprocessors, PropertyPlaceholderConfigurers sounds to me like an SPI. I suppose the point you're really trying to get at is that Spring actually has some built-in XML syntax layered over some of these constructs. It's certainly possible to write a CDI portable extension that provides the same kinds of capabilities over the CDI SPI. The Resin folks have already done this, and we are already working on our own version. But the more I think about this stuff, the less interesting it seems. I can do all the stuff you use Spring XML for using Java. And it's usually more elegant, easier to read, and easier to refactor.

Give us some concrete problems, and I'll tell you how to solve them in CDI. Yes, my solution will probably involve Java code, not XML. And that's a good thing.

Just don't spread the pure JavaEE or you suck FUD.

I certainly didn't say anything like that. Instead, I wrote:

Now, of course, I'm sure there are plenty of good reasons to choose a non-standard open source technology as an alternative to, or in addition to, a technology included in the EE platform. Happily, you're free to use whatever open source frameworks you like in EE 6 - indeed, Servlet 3 and CDI include a bunch of functionality to make integration of third-party frameworks as seamless as possible.
You're promoting Seam - even if it will be CDI SPI extension it'll still be Seam - you'll have to include it in your WAR/EAR. Just like Spring.

Seam 3 is not a bean container, nor a programming model. That side of things is now all well-defined by EE 6. Seam 3 is a set of very focused, independent, portable extensions that solve very specific problems. And these portable extensions will play nicely with portable extensions authored by other groups. So I don't see how Seam 3 is like Spring at all.

 
08. Jan 2010, 14:42 CET | Link

Well, actually, you did give a concrete problem, wire a filled Map. That's a little short on details about what you're really trying to achieve, but if I take a guess, you don't want to make the Map available for injection to other objects, what you're really trying to do is configure a Map property of another bean. So here's one solution in CDI:

@Alternative 
class DeploymentSpecificConfiguration

  @Produces 
  static Foo<Baz> configureFoo(@New Foo<Baz> foo, @New HashMap<Bar, Baz> map) {
    //add the map elements 
    map.put(...);
    map.put(...);
    ...
    foo.setMap(map);
    return foo;
  }

  //other deployment-specific configuration
  ...

}

Now, enable DeploymentSpecificConfiguration in beans.xml if it should be used instead of the default configuration.

Notice, that unlike the XML-based solution, this code is typesafe, right down to the types of the map keys and values, and the type parameter of the injectable Foo. And the code can be easily refactored in an IDE.

 
08. Jan 2010, 16:28 CET | Link
Alberto Gori
Gavin King wrote on Jan 08, 2010 08:18:
Um, sure, I suppose so. And how do you do it in Spring? Using XML? How is that possibly better? The code you write in XML is less typesafe, more verbose, less toolable, less refactorable. CDI let's you write that code in Java, and, using @Alternative, have it be deployment-specific, just like your Spring XML is.

Usually people confuses external configuration files with classpath resources (like Spring xml). An xml inside a WAR is not supposed to be edited from customers, that's why Java code is better in these situations.

 
08. Jan 2010, 16:33 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com

Thanks Gavin for the reply!

I've read the entire JSR299 spec. I like it's strongly-typed, it's @Qualifiers, @Producers, but after reading the spec with existing Spring app in mind I have some questions/observations:
  • How can you wire a filled Map? (configuration or some high-level mapping)
  • Are @Producer methods the only (non-extension) way to return filled Map?
Um, sure, I suppose so. And how do you do it in Spring? Using XML? How is that possibly better? The code you write in XML is less typesafe, more verbose, less toolable, less refactorable. CDI let's you write that code in Java, and, using @Alternative, have it be deployment-specific, just like your Spring XML is.

Of course XML is not refactorable - nobody designed it like that. But telling that now you can get rid of all of your XML with framework XYZ is only FUD. XML is great for describing higher level concepts. E.g. writing mapping from some bussiness specific code to SoapAction is better described in XML or properties file than Java code. And strings (AFAIK) are still not refactorable.

  • Isn't the entire SPI concept just a nice and diplomatic way to hide a fact that CDI is just ... simple DI? Spring's DI container has many concepts of BeanPostprocessors, BeanFactoryPostprocessors, PropertyPlaceholderConfigurers, bean definition inheritance, method injection. Isn't SPI a way to tell If you want it, write/buy/get an extension provider?
Well, I guess BeanPostprocessors, BeanFactoryPostprocessors, PropertyPlaceholderConfigurers sounds to me like an SPI. I suppose the point you're really trying to get at is that Spring actually has some built-in XML syntax layered over some of these constructs. It's certainly possible to write a CDI portable extension that provides the same kinds of capabilities over the CDI SPI. The Resin folks have already done this, and we are already working on our own version. But the more I think about this stuff, the less interesting it seems. I can do all the stuff you use Spring XML for using Java. And it's usually more elegant, easier to read, and easier to refactor. Give us some concrete problems, and I'll tell you how to solve them in CDI. Yes, my solution will probably involve Java code, not XML. And that's a good thing.

Again about SPI - how can I be sure, that particular App Server has that one specific CDI extension? About keeping everything in Java - how about JDBC configuration for six different datasources? (I know of @DataSourceDefinition) Do you keep passwords in Java or in properties files? Separation princple talks about keeping things that change from things that stay the same.

Just don't spread the pure JavaEE or you suck FUD.
I certainly didn't say anything like that. Instead, I wrote: Now, of course, I'm sure there are plenty of good reasons to choose a non-standard open source technology as an alternative to, or in addition to, a technology included in the EE platform. Happily, you're free to use whatever open source frameworks you like in EE 6 - indeed, Servlet 3 and CDI include a bunch of functionality to make integration of third-party frameworks as seamless as possible. You're promoting Seam - even if it will be CDI SPI extension it'll still be Seam - you'll have to include it in your WAR/EAR. Just like Spring. Seam 3 is not a bean container, nor a programming model. That side of things is now all well-defined by EE 6. Seam 3 is a set of very focused, independent, portable extensions that solve very specific problems. And these portable extensions will play nicely with portable extensions authored by other groups. So I don't see how Seam 3 is like Spring at all.

Sure, Spring is not a set of CDI extensions. But if I use Seam (I can see some cases where I could use it) I want to think about it as Seam, not as some hidden SPI implementations. Just like with commons-logging/slf4j + log4j. I use CL/SLF4J, but I'm aware of log4j and write (hey - in XML!) log4j configuration.

regards Grzegorz Grzybek

 
08. Jan 2010, 16:39 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com
Gavin King wrote on Jan 08, 2010 08:42:
Well, actually, you did give a concrete problem, wire a filled Map. That's a little short on details about what you're really trying to achieve, but if I take a guess, you don't want to make the Map available for injection to other objects, what you're really trying to do is configure a Map property of another bean. So here's one solution in CDI:
@Alternative 
class DeploymentSpecificConfiguration

  @Produces 
  static Foo<Baz> configureFoo(@New Foo<Baz> foo, @New HashMap<Bar, Baz> map) {
    //add the map elements 
    map.put(...);
    map.put(...);
    ...
    foo.setMap(map);
    return foo;
  }

  //other deployment-specific configuration
  ...

}
Now, enable DeploymentSpecificConfiguration in beans.xml if it should be used instead of the default configuration. Notice, that unlike the XML-based solution, this code is typesafe, right down to the types of the map keys and values, and the type parameter of the injectable Foo. And the code can be easily refactored in an IDE.

The strings you put in map are neither type-safe nor refactorable.

About real problem - I want to inject a map with some codes as keys and services as values. HTTP requests indicates the code and map provides concrete implementation for e.g. validation or transformation of request. Suppose there is about 20 entries in a map - each entry maps to a differenc implementation. To stay type-safe with CDI, the @Producer method should have 20 injection points... I prefer XML way.

regards Grzegorz Grzybek

 
08. Jan 2010, 19:00 CET | Link
Alberto Gori
Grzegorz Grzybek wrote on Jan 08, 2010 10:39:
The strings you put in map are neither type-safe nor refactorable.

Not anything needs to be type-safe.

About real problem - I want to inject a map with some codes as keys and services as values. HTTP requests indicates the code and map provides concrete implementation for e.g. validation or transformation of request. Suppose there is about 20 entries in a map - each entry maps to a differenc implementation. To stay type-safe with CDI, the @Producer method should have 20 injection points... I prefer XML way.

Could you give an example of Spring xml snippet solving this real problem?

 
08. Jan 2010, 19:51 CET | Link
Grzegorz Grzybek wrote on Jan 08, 2010 10:33:
Of course XML is not refactorable - nobody designed it like that.

Right, so you should be very careful what you use it for. In particular, it doesn't make a great scripting language (which is more or less what Spring configuration amounts to).

But telling that now you can get rid of all of your XML with framework XYZ is only FUD.

Please stop calling things FUD just because you disagree with them. And I never said that CDI get(s) rid of all of your XML. Just most of it.

XML is great for describing higher level concepts.

What makes a concept higher level, in your mind?

E.g. writing mapping from some bussiness specific code to SoapAction is better described in XML or properties file than Java code. And strings (AFAIK) are still not refactorable.

I don't really understand your example. Please show the Spring XML configuration to solve this problem. Then I'll show you the equivalent solution in CDI.

Again about SPI - how can I be sure, that particular App Server has that one specific CDI extension?

I guess you've missed the whole point of the SPI. Every CDI portable extension runs on every application server. That's why it's called a portable extension. That's the whole point.

About keeping everything in Java - how about JDBC configuration for six different datasources? (I know of @DataSourceDefinition) Do you keep passwords in Java or in properties files?

Most application servers provide an XML-based approach to configuring DataSources. You should use whatever mechanism is supported by your application server. I don't see how this is really relevant to the discussion.

Separation princple talks about keeping things that change from things that stay the same.

And you can't separate things things into different classes in Java? And CDI doesn't have the notion of @Alternative beans to accommodate deployment-specific changes?

Sure, Spring is not a set of CDI extensions. But if I use Seam (I can see some cases where I could use it) I want to think about it as Seam, not as some hidden SPI implementations. Just like with commons-logging/slf4j + log4j. I use CL/SLF4J, but I'm aware of log4j and write (hey - in XML!) log4j configuration.

What's hidden about them? I don't understand this point at all.

 
08. Jan 2010, 20:14 CET | Link
Grzegorz Grzybek wrote on Jan 08, 2010 10:39:
The strings you put in map are neither type-safe nor refactorable.

Oh but what if you decided to use enums, instead of strings?

About real problem - I want to inject a map with some codes as keys and services as values. HTTP requests indicates the code and map provides concrete implementation for e.g. validation or transformation of request. Suppose there is about 20 entries in a map - each entry maps to a differenc implementation. I prefer XML way.

I'm sorry, but this sounds just nuts to me. This incredibly difficult problem of Map<String,Class<?>> construction in Java was solved several years ago by the put() method. The idea that I need XML for this is just absurd.

Notice that this problem has nothing to do with configuration at all. There's nothing deployment specific about this mapping.

To stay type-safe with CDI, the @Producer method should have 20 injection points...

Nonsense. This is one way to solve the problem in CDI:

public class Services 

  private Map<Code, Class<? extends Service>> 
    = new HashMap<Code, Class<? extends Service>>();
  {
    map.put(Code.SOME_CODE, SomeService.class);
    map.put(Code.SOME_OTHER_CODE, SomeOtherService.class);
    ...
  }

  @Inject Instance<Service> serviceInstance:

  public <T extends Service> T get(String code) {
    return serviceInstance.select( map.get( Enum.valueOf(Code.class, code) ) ).get();
  }

}
I prefer XML way.

Why. What advantage does it offer? Let's see your XML-based implementation of my Services class.

 
08. Jan 2010, 20:16 CET | Link

By the way, notice that SomeService and SomeOtherService are just service interfaces. The actual bean that implements the interface may vary at deployment time, depending upon what alternatives are enabled.

 
08. Jan 2010, 21:06 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com
Alberto Gori wrote on Jan 08, 2010 13:00:
About real problem - I want to inject a map with some codes as keys and services as values. HTTP requests indicates the code and map provides concrete implementation for e.g. validation or transformation of request. Suppose there is about 20 entries in a map - each entry maps to a differenc implementation. To stay type-safe with CDI, the @Producer method should have 20 injection points... I prefer XML way.
Could you give an example of Spring xml snippet solving this real problem?

Ok, Gavin wrote about @Inject Instance\<...\> - I get it. About my example - XML is simple - one line per code-service mapping. The same may be described with properties file. I just like to keep metadata/configuration outside java classes.

 
08. Jan 2010, 21:18 CET | Link
Alberto Gori
Grzegorz Grzybek wrote on Jan 08, 2010 15:06:
Ok, Gavin wrote about @Inject Instance\<...\> - I get it. About my example - XML is simple - one line per code-service mapping. The same may be described with properties file.

Provide your snippet please, so that we can discuss about it.

I just like to keep metadata/configuration outside java classes.

Why? In Eclipse you can configure multiple source folders. For example

-src/main/java/com/mycompany/...

-src/main/config/Services.java

So you can separate a little the concepts.

In other languages (for example Python) developers already use their own (usually scripting) language instead of xml for configuration. I think Java developers can do the same.

 
08. Jan 2010, 21:44 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com
Provide your snippet please, so that we can discuss about it.

There is nothing to discuss about. I know I can choose between <entry key="x" ref="y" /> and map.put("x", y). I chose XML because for me that's configuration, not code. If I was a Ruby programmer, I could choose YAML, for JavaScript I could use JSON and so on. For Java I chose XML where it fits.

I just like to keep metadata/configuration outside java classes.
Why? In Eclipse you can configure multiple source folders. For example -src/main/java/com/mycompany/... -src/main/config/Services.java So you can separate a little the concepts. In other languages (for example Python) developers already use their own (usually scripting) language instead of xml for configuration. I think Java developers can do the same.

I'm using Maven project layout and usually keep properties and XML files in src/main/resources dir. Of course the argument of not recompiling code after configuration change is deprecated, but I feel better mentally to put config in plain text files.

regards Grzegorz Grzybek

 
08. Jan 2010, 22:13 CET | Link
Scott Peterson

It's not just politics that keeps organizations from upgrading to JEE 6 app servers. In my company, making a switch from WebSphere to JBoss would require time from both the infrastructure group and the development group(s). Now that every company on earth has pared back to the bone, it's hard to get that prioritized. Also, most infrastructure groups try to run as few app server versions as possible in order to lower their ongoing support costs.

On the other hand, there are plenty of political turf wars involved here too. Sad but true.

Isn't there a way to use Weld outside a JEE 6 container? It does run inside a JUnit test after all. I'm pretty sure JSF 2 will work fine in Tomcat. If I can bundle these jars in my war and use them just like I can use Spring, what's the big hold up? You can grant the premise of this argument but not the conclusion. If I can bundle Spring jars in my app I can bundle Weld or Resin too.

 
08. Jan 2010, 22:30 CET | Link
Alberto Gori
Scott Peterson wrote on Jan 08, 2010 16:13:
It's not just politics that keeps organizations from upgrading to JEE 6 app servers. In my company, making a switch from WebSphere to JBoss would require time from both the infrastructure group and the development group(s). Now that every company on earth has pared back to the bone, it's hard to get that prioritized. Also, most infrastructure groups try to run as few app server versions as possible in order to lower their ongoing support costs. On the other hand, there are plenty of political turf wars involved here too. Sad but true. Isn't there a way to use Weld outside a JEE 6 container? It does run inside a JUnit test after all. I'm pretty sure JSF 2 will work fine in Tomcat. If I can bundle these jars in my war and use them just like I can use Spring, what's the big hold up? You can grant the premise of this argument but not the conclusion. If I can bundle Spring jars in my app I can bundle Weld or Resin too.

AFAIK, Weld can run in Java SE. But If you are in a servlet environment you need Servlet 3 specification. And you can't upgrade servlet version without upgrading the servlet container. Am I wrong?

 
08. Jan 2010, 23:02 CET | Link
Scott Peterson wrote on Jan 08, 2010 16:13:
It's not just politics that keeps organizations from upgrading to JEE 6 app servers. In my company, making a switch from WebSphere to JBoss would require time from both the infrastructure group and the development group(s). Now that every company on earth has pared back to the bone, it's hard to get that prioritized. Also, most infrastructure groups try to run as few app server versions as possible in order to lower their ongoing support costs. On the other hand, there are plenty of political turf wars involved here too. Sad but true. Isn't there a way to use Weld outside a JEE 6 container?

It runs in Java SE and Servlet (Jetty and Tomcat tested, GAE should work, regular tests expected soon :-) - of course, you don't get EJB etc. integration ootb. Currently you don't get ootb support for other bits that will run in an EE env (like @Inject Validator validator; or @PersistenceContext EntityManager em) - bur we are working on that.

I'm pretty sure JSF 2 will work fine in Tomcat.

It does :-)

If I can bundle Spring jars in my app I can bundle Weld or Resin too.

Yes you can do this (well, not with Resin AFAIK, it has CDI built into it's core, but you could with OWB for example). However the real argument being had is about whether it is better to home-grow your stack, or use a pre-built one. We believe a pre-built one is best, but recognize that this isn't right for everyone (perhaps they have a recalcitrant IT ops group who refuse to install a modern server in production), which is why we offer this kind of Servlet container support.

Alberto Gori wrote on Jan 08, 2010 16:30:
AFAIK, Weld can run in Java SE. But If you are in a servlet environment you need Servlet 3 specification. And you can't upgrade servlet version without upgrading the servlet container. Am I wrong?

You don't need Servlet 3, Servlet 2.5 is just fine :-)

 
08. Jan 2010, 23:35 CET | Link
Scott Peterson
It runs in Java SE and Servlet (Jetty and Tomcat tested, GAE should work, regular tests expected soon :-) - of course, you don't get EJB etc. integration ootb. Currently you don't get ootb support for other bits that will run in an EE env (like @Inject Validator validator; or @PersistenceContext EntityManager em) - bur we are working on that.

Thanks Pete. Is it documented anywhere what is and isn't supported outside a JEE 6 environment? One of the nice things about Spring is that it's easy to add pre-built and pre-tested features with predictable results. So, if I want just the core, I can do that. If I want to add security, I add the Spring Security jars and I get it. If I want to add JSF or webflow support, I add a few more jars and I have that.

With CDI I'm afraid I'll need transactions or LDAP or JSF integration or feature XYZ, and then I'll find out it works great in JEE 6 but for my situation it requires a bunch of custom code.

 
08. Jan 2010, 23:38 CET | Link
Grzegorz Grzybek wrote on Jan 08, 2010 15:06:
About my example - XML is simple - one line per code-service mapping. The same may be described with properties file.

Actually I doubt that your XML is quite that simple. C'mon, 'fess up. Show us the XML and Java code that you had to write to achieve the same thing I did in 5+N lines of Java code. I bet you use more total lines of code. And worse, you need to split it across two files to make it harder to understand.

I just like to keep metadata/configuration outside java classes.

But this is not configuration! What possible advantage is there to keeping it outside of the typesafe Java code? I can see only disadvantages.

And even if it truly were configuration, CDI is actually designed to let you write configuration-specific stuff in Java. Which is a great feature.

 
08. Jan 2010, 23:42 CET | Link
Scott Peterson wrote on Jan 08, 2010 17:35:
With CDI I'm afraid I'll need transactions or LDAP or JSF integration or feature XYZ, and then I'll find out it works great in JEE 6 but for my situation it requires a bunch of custom code.

One of the goals of Seam3 is to provide the missing bits that you'll need when you run CDI on a servlet engine (transaction management and JPA integration, for example). And this stuff will work with any CDI implementation.

 
08. Jan 2010, 23:46 CET | Link
Dennis Doubleday | dennis.doubleday(AT)gmail.com

I agree with Scott, it is a resource prioritization issue. Java EE 6 is probably very good. I base that opinion not on detailed knowledge of the spec and reference implementation but on the trust that Gavin has built up by delivering Hibernate, a great technology.

Unfortunately for me, Java EE 6 is years too late. I led the development of an app technology base built on Spring/Hibernate/WebWork (now Struts 2), and my company has now built several large apps on this base. We have expended many person-years on this effort, and now have a core developer group that is very comfortable with the technologies. There is no way I will be able to go back to the executive level and say we now need to spend many person years (development plus QA) converting all this work to standards-based technologies so that we can end up with applications that do exactly what they do today (except for the new bugs introduced by this porting activity). Actually, even that isn't true, because we depend on Hibernate features that didn't make it in to JPA.

I would probably use Java EE 6 if I changed jobs and had to build something from scratch again. But it won't happen here. We have too much other work to do.

 
08. Jan 2010, 23:51 CET | Link
There is nothing to discuss about. I know I can choose between <entry key="x" ref="y" /> and map.put("x", y). I chose XML because for me that's configuration, not code. If I was a Ruby programmer, I could choose YAML, for JavaScript I could use JSON and so on. For Java I chose XML where it fits.

I hope you now see that you chose XML because that is what Spring encourages and because that is what you're used to. Not because it's the only way to solve the problem, or even the best way to solve the problem.

CDI is not Spring. The folks who created CDI are not Spring fans. Most of us think that the fashion for programming in XML is a bad thing that has led to a mountain of code that is difficult to understand, refactor and maintain (by humans, and tools). It's led to a crazy mindset where just about anything might be considered configuration, even if it never actually changes between deployments of the system. It's a disease particular to the Java community. Programmers outside of the Java community don't do things this way. They aren't addicted to configuration, and to splitting their code between two languages.

So when you approach CDI, you need to take a step back from your this is how I do it in Spring worldview and explore a different way to do it, which uses plain, typesafe Java code.

 
08. Jan 2010, 23:57 CET | Link
There is no way I will be able to go back to the executive level and say we now need to spend many person years (development plus QA) converting all this work to standards-based technologies so that we can end up with applications that do exactly what they do today (except for the new bugs introduced by this porting activity).

Of course not. We didn't design this stuff to be used to rewrite huge legacy Spring/Hibernate applications. That's just not a very interesting problem, and of no real value to anyone. Instead we designed something that is for use in new development. Of course, once we get a couple of portable extensions written, Spring and CDI will interoperate very elegantly, so you'll be able to use them side-by-side in the same application. (CDI for new functionality.)

 
09. Jan 2010, 00:48 CET | Link
Your customers do have the choice to use GlassFish (which is available now) or JBoss (which will be available soon). If they choose, for their own masochistic reasons, not to take full advantage of the choices that are available to them, we should be criticizing them, not criticizing Java EE.

This might help the developers, but not the administrators. When it comes to general reliability, and facilities for management and monitoring, GlassFish 3 (or even 2, for that matter) is not and probably never will be in the same league as WebSphere 6/7 or WebLogic.

 
09. Jan 2010, 01:00 CET | Link
sys wrote on Jan 08, 2010 18:48:
Your customers do have the choice to use GlassFish (which is available now) or JBoss (which will be available soon). If they choose, for their own masochistic reasons, not to take full advantage of the choices that are available to them, we should be criticizing them, not criticizing Java EE. This might help the developers, but not the administrators. When it comes to general reliability, and facilities for management and monitoring, GlassFish 3 (or even 2, for that matter) is not and probably never will be in the same league as WebSphere 6/7 or WebLogic.

But Tomcat/Jetty are better?

 
09. Jan 2010, 01:29 CET | Link
But Tomcat/Jetty are better?

Uh-uh. My observation was limited to JEE servers. I agree with you about homegrown stacks; I'd trust such a thing only if it was made by somebody who's also made successful JEE application servers in the past :)

So my original post was a bit off-topic? Yes...

09. Jan 2010, 02:08 CET | Link
sys wrote on Jan 08, 2010 18:48:
This might help the developers, but not the administrators. When it comes to general reliability, and facilities for management and monitoring, GlassFish 3 (or even 2, for that matter) is not and probably never will be in the same league as WebSphere 6/7 or WebLogic.

Was there something specific Glassfish v3 is missing?

I was quite impressed by the administration console and especially their command line administration features, but I haven't used WebSphere and WebLogic for a long time, so perhaps I don't know what I am missing.

We have begun to evaluate Java EE 6 on GF for a large clustered project and anticipate it driving administration costs down through the CLI. We're expecting it to dramatically reduce development costs as well. Cobbling together various frameworks for use on Tomcat and dealing with the various bugs that ensued has proven to be very costly on past projects. We think Java EE 6 will go a long way letting us stop wasting time integrating frameworks and focus on writing useful applications.

 
09. Jan 2010, 02:32 CET | Link
Dennis Doubleday | dennis.doubleday(AT)gmail.com
Gavin King wrote on Jan 08, 2010 17:57:
There is no way I will be able to go back to the executive level and say we now need to spend many person years (development plus QA) converting all this work to standards-based technologies so that we can end up with applications that do exactly what they do today (except for the new bugs introduced by this porting activity). Of course not. We didn't design this stuff to be used to rewrite huge legacy Spring/Hibernate applications. That's just not a very interesting problem, and of no real value to anyone.

OK. But the point of your post was that you didn't understand resistance to upgrade. It is just a fact that uptake will be slow because most projects aren't new work and Spring/Hibernate plus whatever View framework captured a lot of mindshare from 2003-2009.

 
09. Jan 2010, 02:38 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com
Gavin King wrote on Jan 08, 2010 13:51:
Grzegorz Grzybek wrote on Jan 08, 2010 10:33:
Of course XML is not refactorable - nobody designed it like that.
Right, so you should be very careful what you use it for. In particular, it doesn't make a great scripting language (which is more or less what Spring configuration amounts to).

For me argumenting that XML is bad scripting language is like saying that EJB2 is bad component model. It's obvious and proven years ago. For me Spring configuration is not scripting. Just look at Spring Security <http /> configuration.

But telling that now you can get rid of all of your XML with framework XYZ is only FUD.
Please stop calling things FUD just because you disagree with them. And I never said that CDI get(s) rid of all of your XML. Just most of it.
XML is great for describing higher level concepts.
What makes a concept higher level, in your mind?

E.g. mapping URL root's to controlers - more detailed mapping may be configured with annotations. And I'm aware of Servlets 3's annotations - but you can't configure existing servlets with them.

E.g. writing mapping from some bussiness specific code to SoapAction is better described in XML or properties file than Java code. And strings (AFAIK) are still not refactorable.
I don't really understand your example. Please show the Spring XML configuration to solve this problem. Then I'll show you the equivalent solution in CDI.

Gavin - I know that I can use map.put() in @Producer methods. And CDI's Instance<xxx> looks very clever (just like Spring's ServiceLocatorFactoryBean. I just like to keep configuration (or what I think is configuration) outside Java.

Again about SPI - how can I be sure, that particular App Server has that one specific CDI extension?
I guess you've missed the whole point of the SPI. Every CDI portable extension runs on every application server. That's why it's called a portable extension. That's the whole point.

OK, I don't know the details, but I'm pretty sure that these extensions are not deployed to some appserver's specific dir, but comes with your WAR/EAR. Just like Spring. So generally - you can't tell people that they have to have their WEB-INF/lib filled only with their own JARs - that JavaEE has it all.

About keeping everything in Java - how about JDBC configuration for six different datasources? (I know of @DataSourceDefinition) Do you keep passwords in Java or in properties files?
Most application servers provide an XML-based approach to configuring DataSources. You should use whatever mechanism is supported by your application server. I don't see how this is really relevant to the discussion.

This part was about XML config. CDI allows only to define alternatives, interceptors and decorators in beans.xml. My example with datasources concerns application which don't have to run in app server. It's still about my division into code and config. I can put DataSource config into @Producer (or e.g. LDAP connection settings) but I prefer XML/properties file.

Separation princple talks about keeping things that change from things that stay the same.
And you can't separate things things into different classes in Java? And CDI doesn't have the notion of @Alternative beans to accommodate deployment-specific changes?

Of course I can. But for me the cleaner way is to select different properties files with Maven profiles than different java classes. Maven profile could define different CDI's beans.xml, but beans.xml concerns different aspects than spring's XML config.

Sure, Spring is not a set of CDI extensions. But if I use Seam (I can see some cases where I could use it) I want to think about it as Seam, not as some hidden SPI implementations. Just like with commons-logging/slf4j + log4j. I use CL/SLF4J, but I'm aware of log4j and write (hey - in XML!) log4j configuration.
What's hidden about them? I don't understand this point at all.

By hidden I mean not treated as first class API and sticking with pure JavaEE api. Just like Hibernate gives me more than JPA - I'm using Hibernate API and not pure JPA API just for purity.

Grzegorz Grzybek wrote on Jan 08, 2010 10:39:
The strings you put in map are neither type-safe nor refactorable.
Oh but what if you decided to use enums, instead of strings?

That's not the point

About real problem - I want to inject a map with some codes as keys and services as values. HTTP requests indicates the code and map provides concrete implementation for e.g. validation or transformation of request. Suppose there is about 20 entries in a map - each entry maps to a differenc implementation. I prefer XML way.
I'm sorry, but this sounds just nuts to me. This incredibly difficult problem of Map<String,Class<?>> construction in Java was solved several years ago by the put() method. The idea that I need XML for this is just absurd. Notice that this problem has nothing to do with configuration at all. There's nothing deployment specific about this mapping.

It's still about what's config and what's code. For me a filled map is config. And I like it in XML or other non-Java. But I also value clarity of Java config - there is place for that in my code.

To stay type-safe with CDI, the @Producer method should have 20 injection points...
Nonsense. This is one way to solve the problem in CDI:
I prefer XML way.
Why. What advantage does it offer? Let's see your XML-based implementation of my Services class.

Thanks for the Instance<xxx> example. I've read JSR299 once. That's really clever. I also recall that Spring has such mechanism implemented in ServiceLocatorFactoryBean.

I hope you now see that you chose XML because that is what Spring encourages and because that is what you're used to. Not because it's the only way to solve the problem, or even the best way to solve the problem.

In 2004 everyone chose XML for Spring. Just like in 2002 everyone chose XML for everything - from databases to HTML pages transformation. Now in practice I use XML where it makes my job easier. CDI is good (I've said that), Java EE is good, but in practice there should be no use pure JavaEE manifesto. Someone said on TSS, that after JavaEE 6, the rationale behind Spring is no longer valid. Why? Spring has many classes which simplify day-to-day job. I've writen on TSS about ReflectionUtils and others. Spring is not DI. Spring is not against Java EE. All I want to say, that your opinions make people think that now only Java EE matters.

CDI is not Spring. The folks who created CDI are not Spring fans. Most of us think that the fashion for programming in XML is a bad thing that has led to a mountain of code that is difficult to understand, refactor and maintain (by humans, and tools). It's led to a crazy mindset where just about anything might be considered configuration, even if it never actually changes between deployments of the system.

Maybe you're not Spring fan - I remember your opinions about HibernateTemplate. But saying that Spring = fasion for programming in XML is like saying that JavaEE = EJB2.

It's a disease particular to the Java community. Programmers outside of the Java community don't do things this way. They aren't addicted to configuration, and to splitting their code between two languages.

Tell this to .NET developers who are told from the very beginning that it's the real power of .NET - to write a class in C# and derive from it in VB :)

So when you approach CDI, you need to take a step back from your this is how I do it in Spring worldview and explore a different way to do it, which uses plain, typesafe Java code.

I understand. CDI is a good spec - especially in keeping the safety of types. It'll sure find its uses. JavaEE is also very good and modern set of specifications. But for real projects I need more. Not something different, but something more, something I can rely on because it's on my classpath, for which I have source code and JIRA+public forums address. Hibernate gives me all that and Spring (security, integration, ldap, osgi, ws, framework) gives me all that.

So keep up good work and don't get too fanatic about that :)

 
09. Jan 2010, 03:43 CET | Link
For me Spring configuration is not scripting.

Looks like scripting to me. Whatever it is, it's definitely not configuration, since most of it doesn't change between deployments.

E.g. mapping URL root's to controlers - more detailed mapping may be configured with annotations.

Honestly, this sounds like something that web frameworks do, not dependency injection containers. And it's certainly not configuration. And I think we all figured out a while ago that doing this in XML is just a really bad approach. None of the current crop of web frameworks takes this approach.

So, the only use case you've come up with so far is not only not a usecase for dependency injection, but it's not even current industry best practice.

I just like to keep configuration (or what I think is configuration) outside Java.

You keep saying this, but you offer zero reasoning for why it's a good idea. I've given several reasons for why it's a bad idea to put what you think is configuration (which is not actually configuration) in XML. And you've offered no counter-argument. It sounds to me like the only reason you like it is that you're used to it.

I can put DataSource config into @Producer (or e.g. LDAP connection settings) but I prefer XML/properties file.

As far as I am aware, pretty much everyone prefers this. So I'm not sure who you're arguing with. CDI doesn't having anything to say about configuring datasources.

And you can't separate things things into different classes in Java? And CDI doesn't have the notion of @Alternative beans to accommodate deployment-specific changes?
Of course I can. But for me the cleaner way is to select different properties files with Maven profiles than different java classes.

You clearly have not understood how a CDI @Alternative works. Go back and read the spec again.

By hidden I mean not treated as first class API and sticking with pure JavaEE api.

I really don't understand your point. You don't use any third-party jars in your application? That's all a portable extension is.

I'm not even sure why we're discussing portable extensions at this juncture, since you have not yet shown us a problem that you need a portable extension for. The problem we were discussing is solvable without any portable extensions.

Just like Hibernate gives me more than JPA - I'm using Hibernate API and not pure JPA API just for purity.

Well a portable extension is much better that Hibernate's vendor-specific extensions, since a portable extension runs against any CDI implementation. Hibernate's extensions tie you to Hibernate.

Frankly, you're not making any sense at all here. You don't like third-party jars so you use Spring and Hibernate instead? What are Spring and Hibernate?

The strings you put in map are neither type-safe nor refactorable.
Oh but what if you decided to use enums, instead of strings?
That's not the point

Oh but it's exactly the point. Spring has warped your brain into thinking of all problems in terms of nontypesafe XML and strings. That's why you don't get CDI. CDI just isn't about writing bad non-typesafe, unrefactorable code in XML and then mapping it to Java using non-typesafe string-based identifiers. CDI is a whole different, better, easier paradigm.

CDI is good (I've said that), Java EE is good, but in practice there should be no use pure JavaEE manifesto.

Please provide a link to this manifesto. AFAIK, it doesn't reflect anything I've said. Who are you arguing with?

Someone said on TSS, that after JavaEE 6, the rationale behind Spring is no longer valid.

Ah, Someone. Link? It certainly wasn't me who said that.

Why? Spring has many classes which simplify day-to-day job.

Which is why I proposed on the famous TSS thread that the Spring folks get these many classes working with CDI, using the portable extension SPI. The response from the Spring folks was that this would be too much work, and they didn't want to get distracted, or something like that. Weak.

All I want to say, that your opinions make people think that now only Java EE matters.

Even though what I actually wrote said the precise opposite of that. Right. Please stop confusing me with Someone.

Maybe you're not Spring fan - I remember your opinions about HibernateTemplate. But saying that Spring = fasion for programming in XML is like saying that JavaEE = EJB2.

I'm sorry? You just spent several posts touting the advantages of Spring by making the case for XML. And now you chastise me for criticizing Spring for encouraging the use of XML?! How does that work? Are you now denying that Spring encouraged a lot of people to write a lot of XML? Really? Even though it seems to have encouraged you to use a lot of XML? Even though you just finished arguing that this was what was good about Spring?

Perhaps you have some other reason for preferring Spring to CDI. If so let's hear it. So far you have not mentioned anything else.

Tell this to .NET developers who are told from the very beginning that it's the real power of .NET - to write a class in C# and derive from it in VB :)

This seems to be a pretty irrelevant observation, since the reasons for doing this would have nothing at all to do with configuration. Oh and since both C# and VB are real programming languages.

I understand. CDI is a good spec - especially in keeping the safety of types. It'll sure find its uses. JavaEE is also very good and modern set of specifications. But for real projects I need more.

Define more.

Not something different, but something more,

Again, define more.

something I can rely on because it's on my classpath,

Um, WTF? CDI is certainly in your classpath.

for which I have source code and JIRA+public forums address.

Does that help?

Hibernate gives me all that and Spring (security, integration, ldap, osgi, ws, framework) gives me all that.

As do Weld and Seam 3. You're grabbing at straws.

 
09. Jan 2010, 03:52 CET | Link
Dennis Doubleday wrote on Jan 08, 2010 20:32:
OK. But the point of your post was that you didn't understand resistance to upgrade. It is just a fact that uptake will be slow because most projects aren't new work and Spring/Hibernate plus whatever View framework captured a lot of mindshare from 2003-2009.

No, that wasn't the point of my post. Of course I understand that people with existing legacy projects will take longer to migrate to new technology than people with new projects. The point of my post was to debunk four specific arguments which have been deployed to argue against the use of EE 6 in general.

The argument that I have millions of lines of existing code that I don't want to have to rewrite is totally legitimate. It is also not one of the four arguments I responded to in this post.

 
09. Jan 2010, 04:01 CET | Link
sys wrote on Jan 08, 2010 19:29:
But Tomcat/Jetty are better?
Uh-uh. My observation was limited to JEE servers. I agree with you about homegrown stacks; I'd trust such a thing only if it was made by somebody who's also made successful JEE application servers in the past :)

I guess the thing is that so many folks out there have essentially built their own application servers out of spare parts, and put a lot of work into that, and they're proud of it. So they have an emotional investment in their homegrown stack. To be told now that an EE 6 container can do everything their homegrown stack can do, and more, and do it better, puts people a bit on the defensive.

 
09. Jan 2010, 04:16 CET | Link
sys wrote on Jan 08, 2010 18:48:
When it comes to general reliability, and facilities for management and monitoring, GlassFish 3 (or even 2, for that matter) is not and probably never will be in the same league as WebSphere 6/7 or WebLogic.

I would like to disagree, and certainly dispute the good enough open source image painted here (assuming that's what you're implying). GlassFish may not be as battle-tested as the others you mention (it just hasn't been around for long enough) but yet customers do use it to replace these expensive and aging appservers, sometimes company-wide and in very marge corporations.

As for management and monitoring, I think GlassFish does very well with its web console, CLI, RESTful admin API (v3), cluster management, etc. We'd love to hear about missing features as we're now headed towards GlassFish 3.1.

 
09. Jan 2010, 04:19 CET | Link
Gavin King wrote on Jan 08, 2010 22:01:
I guess the thing is that so many folks out there have essentially built their own application servers out of spare parts, and put a lot of work into that, and they're proud of it. So they have an emotional investment in their homegrown stack. To be told now that an EE 6 container can do everything their homegrown stack can do, and more, and do it better, puts people a bit on the defensive.

Right, years back (last century) I used to get my OS from kernel.org and was kind of proud of that ...

09. Jan 2010, 05:08 CET | Link

I should throw in a comment on how nice it can be to do actual configuration in a CDI system based on Resin's implementation, using the case of the opensource SubEtha mailing list server.

Using Resin's CDI, SubEtha lets you override fundamental parameters like what port does the SMTP server run on and where do you send mail that doesn't belong to us in a user-editable XML file (outside the SubEtha war) that directly affects the instantiation of CDI beans. The beans have their own default property values, ie default port is 25 but the injector automatically will override them. An example snippet:

        <smtp:SMTPService>
                <port>2500</port>
                <bindAddress>yourinterface</bindAddress>
                <fallbackHost>localhost:2525</fallbackHost>
        </smtp:SMTPService>

There's nothing special about SMTPService except that it's a CDI-injected bean and it has predictably-named properties.

What isn't in this XML configuration is stuff like email service requires smtp service - this is basic application wiring without which the application is broken. It belongs in Java code.

CDI is cool stuff.

 
09. Jan 2010, 05:19 CET | Link
Senthil

Gavin,

EJB2 Sucked. New version of JEE which is far better. No question about it. In its current form, JEE should be examined based on its merits than saying EJB2 caused lot of problems. That's fair. Similarly Spring should not be touted as bad because it allows XML configurations.

For some people (like you) configuration in XML sucks and some people prefer XML configuration. Spring guys listened to that and now with Spring 3.0 it is possible to eliminate most (if not all) of the configuration in XML. Why can't you acknowledge that there are people who prefer xml way of configuration and base your arguments outside of Spring XML? Spring provides choices. That's what developers want. There is no one-size-fits-all solution.

 
09. Jan 2010, 06:02 CET | Link

I am upgrading to Java EE 6 as fast as I can. I wrote a JEE 5 app in 2005 (before the ink dried on the spec). It is in heavy use and it was painful because of the beta support in the application server. I like everything I see in JEE 6. This time I am converting everything from JBoss to GlassFish. It took JBoss a long time to get JEE 5 right so I am not betting the farm on it again. I really need RichFaces updated for JSF 2 ASAP. PrimeFaces is too weak for what I need.

 
09. Jan 2010, 11:19 CET | Link
Why can't you acknowledge that there are people who prefer xml way of configuration and base your arguments outside of Spring XML?

I was not the one who raised XML configuration or Spring in this thread. I was responding to this post. And no, it's not OK for you to show up here and declare certain discussion topics off limits. This is my blog, and if I want to criticize the fashion for programming in XML, that's what I'm going to do. If it makes you uncomfortable to have your beliefs questioned, stop reading.

 
09. Jan 2010, 18:35 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com

OK Gavin, I'll try to stop blockquoting the entire discussion.

This is my blog, and if I want to criticize the fashion for programming in XML, that's what I'm going to do.

Thanks for the discussion. I knew what I was doing writing a comment in your blog. The main goal of my comment was to use your blog post to refresh some threads that were started in this topic at TSS.

Someone (not you) said:

Java EE has all the functionality now that the old J2EE + Spring can supply. As a trend, Spring is finished, it has done it's historical task.

I don't agree, so I've decided to use my not-so-fluent English and write a comment. I also think that kind of statement is fanatism. Java EE still doesn't have all the functionality of Spring, Seam or other framework. It wasn't created to rule them all! I'll say this one more time - JavaEE is great as a common language, as a base for looking up developers for Java projects, but JavaEE is not a reason to call pragmatic programmers Spring/Seam/other fanboys.

Back to your answers/questions.

About configuration/scripting. For you Spring XML is not config because it (mostly) doesn't change. I understand and even agree. CDI and Spring DI in it's non-configuration aspects may be configured totally without XML - I mean wiring colaborators. CDI does wiring in an elegant, type-safe and refactor-friendly way. Can't you just agree that there is place for something even you can call configuration? That's what J2EE env-entries are for, huh? Example? LDAP URL, role mapping properties file (in my app I have 9 different properties files - per customer and environment - they're picked by Maven profile and assembled in JAR), velocity mail templates (again - one set of templates per customer), ...

OK, mapping URLs maybe wasn't very clever idea. I don't have access to my code now so I wrote something like this. I use annotations for that anyway.

About alternatives. Maybe I don't understand them. But when you have many alternatives (possibly stereotyped) you have to enable only one (stereotype) of them? If beans.xml has too many alternatives, you'll still end with exceptions about resolving dependencies. Weld doc says:

Just remember: There can be only one.

About CDI SPI - I might be wrong but these interfaces are not to be used in client code? That's why they're called SPI. So (correct me) Seam 3 (planned, expected) CDI SPI will, according to spec, give the client (transparently) new beans (services), interceptors, decorators, scopes and annotations? That's good model - my beans will be wired using JSR299 (JSR330 anyone?) and may be injected with seam services. I don't deny this model. And you also wrote the SPI was designed, among others, to integrate Spring. So let's see in a near future who will win. Spring was created to make JavaEE easier (and to compete with EJB2), CDI was originally created (IMO) to compete with Spring. And it's good - for JavaEE and for Spring.

I've also thought about Spring as CDI extension. But technically and practically what's the point (IMO)? Through BeanManager interface, Spring could provide some beans to CDI container. It could AOP them, wrap them in interceptors, decorate them. But (very generally), from the perspective of client's code it would be changing @Autowired to @Inject. Again with my Hibernate/JPA example - I could use @Table from JPA or @Table from Hibernate. I don't have anything against Hibernate's annotations so I use this proprietary Hibernate API and live with the burder of vendor (you/JBoss/RedHat) lock-in.

Well a portable extension is much better that Hibernate's vendor-specific extensions, since a portable extension runs against any CDI implementation. Hibernate's extensions tie you to Hibernate.

I don't understand. Of course - Hibernate is not JPA extension, Seam3 will be CDI extension. But if I use Seam3 beans injected to my classes with BeanManager by CDI, I'll be using Seam3. I won't change it to ... other CDI extension which provides the same services as Seam3? Knowing that under JPA I have Hibernate is good. I'm happy being tied to Hibernate - I won't risk replacing it with TopLink.

Spring has warped your brain into thinking of all problems in terms of nontypesafe XML and strings. That's why you don't get CDI. CDI just isn't about writing bad non-typesafe, unrefactorable code in XML and then mapping it to Java using non-typesafe string-based identifiers. CDI is a whole different, better, easier paradigm.

Spring taught me DI as a counter-solution to service lookup. That's it. XML is only one dialect of configuring bean recipes (which at runtime becomes beans). I can use JavaConfig, I can use annotations, I can directly use BeanDefinitions. CDI is not so different from any other DI container. It's newer, clever, but it's still mainly DI container. Spring portfolio has many projects which are configured in XML (using XSD handlers) - I don't comment. I won't quote config examples. But (talking about XML) for me it's easier to use this XML-DSL to configure Spring-Security or Spring-Integration. I won't replace these configs with Spring JavaConfig or CDI.

XML is still here - there are many debates about XML in different products. For example in Maven. Maven XML is verbose, long, POM doesn't change (so it's not a configuration according to you), but it's de-facto standard. Maybe JavaEE will have special spec for building/configuring projects? I know meny people try to replace Maven's XML with some other DSL (e.g. groovy). Maven 3 has some plans (extensions) like Polyglot Maven - I don't know the details.

Oh and since both C# and VB are real programming languages.

I only wanted to mention .NET - they also have XML in app.configs.

Again, define more.

about more in Spring DI vs. CDI - in Spring I have AOP on top of DI (BeanFactory and ApplicationContext) and on top of AOP I have transaction management. XA where it's needed, JDBC transactions, Hibernate transactions (you said you would change if you could turn back time). Objectively I don't see any particular reason why Spring's AOP/TX/... could not be build on top of CDI SPI.

about more in Spring vs. (I'm not thinking it's actually competition) JavaEE - I have Spring Security which doesn't tie me to appserver (have you ever configured role mapping in WebSphere? it's about few hundred clicks if you're not using perl scripts. And if you want to use 2 LDAPs it's impossible in WebSphere), I have Spring Integration which is better (in terms of EIP implementation) than Mule. JBI is not part of JavaEE. I have Spring LDAP which just simplifies LDAP access, I have Spring webflow which doesn't compete with JSF (actually I've used it with RichFaces) - it just gives nice, declarative way of defining controllers and conversation scope. This more just simplifies my work with JavaEE.

for which I have source code and JIRA+public forums address.

I don't have JIRA access to JPA - I have for Hibernate.

Um, WTF? CDI is certainly in your classpath.

Talking about classpath - my point is - it's better to depend on what's in your WEB-INF/lib than what your container provides under JavaEE compliance label. Even on JBoss 5.1 I carry Hibernate 3.3 jar in my webapp instead of programming to JPA and relying on Hibernate provided by JBoss.

This is my opinion on JavaEE - it's great, but when JPA was released and Hibernate was labeled as JPA RI, I haven't switched to JPA API - it wasn't necessary from my application's point of view. I'm using Session, Critera API and HQL though I'm still saying I'm JavaEE programmer.

Also (another point in discussion about XML) - are we totally done with web.xml? I'm not sure - you can't annotate existing servlets and nowadays it's rare to write your own servlets - you rely on Struts, Wicket, JSF, Spring MVC, Tapestry, Rife, ... provided servlets, configure it and stick your actions/controllers/whatever to them.

To be told now that an EE 6 container can do everything their homegrown stack can do, and more, and do it better, puts people a bit on the defensive.

JBoss EE 5.1 provides Hibernate pre 3.5. I'm using Hibernate 3.5 beta in my apps and I like it. So I have more freedom in choosing the version of library I like and need.

About this comment - it's XML, isn't it? It's configuration, huh? I agree it doesn't says to inject this config in any particular place - it just tells the CDI container it's available. But it still is XML.

And to refresh some threads from TSS:

If framework (and application) developers could rely upon certain APIs (like JTA, or the CDI portable extension SPI) being available everywhere, then life would be just soooooo much simpler for everyone. The mess that we've made of transaction management in enterprise Java is a disgrace. We've got abstractions of abstractions of abstractions .... all with the same three methods: begin(), commit(), rollback(). It's a total disaster. (I'm ashamed of my part in it - I should never ever have let Hibernate or JPA grow their own transaction management abstractions.)

By looking at Tomcat's popularity, I don't think the lack of full JavaEE API is any blocker for developers. They rely on Servlets API. If they need JPA, they include it (Hibernate) in their WEB-INF/lib, if they need Tx, they use what's appropriate - e.g. JDBC transactions - it's toooo late to change it - just like Hibernate transactions. Spring allows to use Hibernate's Sessions and JDBC's Connections in one transaction. Just remember to invoke flush() to see your changes in JDBCs queries. If they need XA, they use JTA (e.g. Atomikos). I agree that there are too many TX APIs with begin(), commit() and rollback(). The .NET's way is to break the backward compatibility and to introduce new API. That's not Java way.

Huh? What does CDI have to do with tx management?

Chapter 9 of Weld doc gives an example of TransactionInterceptor. Just off-topic question - are there any plans to release some CDI SPI concerning Tx management? Or the preferred way is to use EJB3.1 transactions?

Use JBoss, GlassFish or Resin. They're not hard to upgrade. That's the great thing about the EE ecosystem: choice.

My case - we're using WebSphere 6.1 at client's site. It's an upgrade from 5.x. The upgrade to 7.x is practically impossible (application works, client has no budget to upgrade). I tried to smuggle JBoss to dev/test environments - it works great, starts fast. But I can't do it in production. So the other thing about EE is: money. IBM knows we (have to) use WebSphere at that particular client, but it can't see what we deploy there. So we've replaced EAR with WAR (MDBs with task-executors). Now our application uses Spring 3.0.0 (it started with 1.0.2). We upgraded Spring to every major version without any concerns. This is great argument for Spring in that case - and I can extrapolate this case to other projects.

In a very short time, Caucho, JBoss, and other vendors, will release small, non-bloated EE 6 web profile implementations.

Web Profile doesn't contain: JAXB, JAX-WS, JavaMail (to mention only the most interesting specs). That's why Web Profile is not as interesting as it seams. I'm not interested in using server, which has JavaEE compliant label - a server, which can handle my HTTP request (supports ServletAPI) and compile my JSP pages/JSF facelets templates is mostly enough. If I want JAXB, I can include jaxb-api and jaxb-impl from Maven repo in my WEB-INF lib.

That's the essential meaning of my comments - I like to use what's appropriate, proven and opensource. Sometimes JDBC is enough (batch processing) and Spring simplifies my job. Hibernate's API is good, but mixing Hibernate and JDBC is easier with Spring (Hibernate's 3.3 session.connection() was once deprecated - strange, it isn't right now).

I agree it's not you who says pure JavaEE or you suck, but there are people who says that - let's not let them grew stronger.

Finally - it's not easy to comment on your blog - in a positive way :) Let's see what will future hold - how many projects will choose CDI as a foundation (DI is architecture foundation nowadays) and how Spring DI will evolve in this new, JavaEE world. Also - is there any (I'm sure there is) feedback which gives you an idea how CDI 2 could look in JavaEE 7?

 
09. Jan 2010, 22:15 CET | Link
Someone (not you) said:
Java EE has all the functionality now that the old J2EE + Spring can supply. As a trend, Spring is finished, it has done it's historical task.
I don't agree, so I've decided to use my not-so-fluent English and write a comment. I also think that kind of statement is fanatism. Java EE still doesn't have all the functionality of Spring, Seam or other framework.

Look, it's not a statement I wrote, nor do I agree with it 100%. I think it is true that Spring's historical task is no longer relevant, but that certainly doesn't imply that Spring has no role to play. I would love to see Spring rethink its role in the Java ecosystem, and adopt a less antagonistic relationship to Java EE. (Though I'm not at all confident that this will happen.) And obviously there are plenty of projects out there using Spring which are not going to ditch it overnight.

Can't you just agree that there is place for something even you can call configuration? That's what J2EE env-entries are for, huh? Example? LDAP URL, role mapping properties file (in my app I have 9 different properties files - per customer and environment - they're picked by Maven profile and assembled in JAR), velocity mail templates (again - one set of templates per customer), ...

I think everybody agrees with that. But it's not at all clear that the bean container is the right beast to manage this kind of configuration. In fact, from your description, it sounds like you don't currently use Spring XML to manage most of these configuration items (you talk about properties files, velocity templates, etc).

Certainly, in the Java EE architecture, it is not the role of CDI to manage configuration of this kind of infrastructure. Now, a particular application server might go down the path that Resin has gone down and combine CDI with something like OSGi to get a complete CDI-based container infrastructure. In that case, CDI would be used for infrastructure configuration, and you would almost certainly want some XML-based configuration option (which can be a portable extension). Jeff mentions how nicely this works out. But it is something that is well beyond the spec, and certainly is not the role of CDI in most application servers. And I don't think it's something we should be trying to standardize.

About alternatives. Maybe I don't understand them. But when you have many alternatives (possibly stereotyped) you have to enable only one (stereotype) of them?

Right. It can boil down to one line of XML to specify the deployment environment.

If beans.xml has too many alternatives, you'll still end with exceptions about resolving dependencies.

Sure. And if your Spring XML defines too many beans with the bean id "foo" you get an exception too. I doubt that very many Spring developers lie awake at night worrying about this problem.

Well a portable extension is much better that Hibernate's vendor-specific extensions, since a portable extension runs against any CDI implementation. Hibernate's extensions tie you to Hibernate.
I don't understand. Of course - Hibernate is not JPA extension, Seam3 will be CDI extension. But if I use Seam3 beans injected to my classes with BeanManager by CDI, I'll be using Seam3. I won't change it to ... other CDI extension which provides the same services as Seam3? Knowing that under JPA I have Hibernate is good. I'm happy being tied to Hibernate - I won't risk replacing it with TopLink.

You still don't seem to get it. Our CDI implementation is Weld, not Seam3. Weld provides everything you need for dependency injection, interceptors, decorators, events, etc. Many people will be happy just using JSF and Weld together without any portable extensions at all. What Seam3 provides is integration to other non-standard third-party technologies for those applications which want to go beyond the basic Java EE stack.

The relationship between Hibernate and JPA is equivalent to the relationship between Weld and CDI. The relationship between Seam3 and CDI is something very different!

about more in Spring DI vs. CDI - in Spring I have AOP on top of DI (BeanFactory and ApplicationContext) and on top of AOP I have transaction management. XA where it's needed, JDBC transactions, Hibernate transactions (you said you would change if you could turn back time). Objectively I don't see any particular reason why Spring's AOP/TX/... could not be build on top of CDI SPI.

Java EE also has interceptors, JTA, declarative transactions, etc. I'm not sure what more Spring offers here? True AOP? Ugh. AOP is a failed, overengineered technology that should never be part of the EE ecosystem. I have never seen any good, practical use of AOP that I can't solve using EE-style interceptors.

about more in Spring vs. (I'm not thinking it's actually competition) JavaEE - I have Spring Security which doesn't tie me to appserver (have you ever configured role mapping in WebSphere? it's about few hundred clicks if you're not using perl scripts. And if you want to use 2 LDAPs it's impossible in WebSphere), I have Spring Integration which is better (in terms of EIP implementation) than Mule. JBI is not part of JavaEE. I have Spring LDAP which just simplifies LDAP access, I have Spring webflow which doesn't compete with JSF (actually I've used it with RichFaces) - it just gives nice, declarative way of defining controllers and conversation scope. This more just simplifies my work with JavaEE.

All of these things are perfect examples of things that could be CDI portable extensions. I'm not a fan of Spring Security or Spring WebFlow (I think Seam Security and jBPM are much superior), and I don't know anything much about Spring Integration or LDAP, but I'm sure that someone who is a fan of these technologies could easily do the work and integrate them with CDI via the SPI.

And I think that - with the exception of security - these technologies should probably stay in the realm of portable extensions. I don't think EE should include built-in orchestration or integration solutions. (I do think that EE needs a new spec for security, perhaps based along the lines of Seam Security.)

Talking about classpath - my point is - it's better to depend on what's in your WEB-INF/lib than what your container provides under JavaEE compliance label

IMO, this is just nonsense on stilts. But I don't want to waste time arguing about it today. Let me just note that what Java really needs is a decent built-in modularity solution.

Web Profile doesn't contain: JAXB, JAX-WS, JavaMail (to mention only the most interesting specs). That's why Web Profile is not as interesting as it seams.

So a second ago you were arguing that it's better to put these kinds of things in WEB-INF/lib, and now you're complaining the the Web Profile doesn't include them in the server classpath?

Look, we're never going to be able to define a web profile which makes everyone 100% happy. Everyone's going to have their own favorite technologies that they would prefer to be part of the profile. But if we give everyone their pet technologies, then they all come back and complain to us that the profile is bloated. So instead, we included just the technologies that were really needed for writing a web application. It seems to me the the reaction from almost everyone has been extremely positive.

Anyway, I don't see this is a real problem here. If you want to use JAXB, JAX-WS or JavaMail in the web profile, you can. You might even be able to find a vendor who includes these as part of their web profile compliant product. Vendors are allowed to include additional platform technologies.

I'm not interested in using server, which has JavaEE compliant label - a server, which can handle my HTTP request (supports ServletAPI) and compile my JSP pages/JSF facelets templates is mostly enough.

I think it's just crazy to argue that the server should not include basic services that 90% of users need, stuff like JTA, JPA, CDI.

If I want JAXB, I can include jaxb-api and jaxb-impl from Maven repo in my WEB-INF lib.

Right, so what were you complaining about, again?

 
09. Jan 2010, 22:22 CET | Link
I think it's just crazy to argue that the server should not include basic services that 90% of users need, stuff like JTA, JPA, CDI.

In case it's not clear. the difference between JTA/JPA/CDI and JavaMail is that the first three technologies are foundational technologies that other technologies integrate with and are built upon. They lay the foundation of an ecosystem. JavaMail, not so much.

 
10. Jan 2010, 00:07 CET | Link

I'm sure Spring will adapt CDI sooner or later, say before Dec 21, 2012 ;-) They have a huge userbase so if they set out to write good, non-portable extensions, then Seam will have to watch out...

 
10. Jan 2010, 00:08 CET | Link

Uhm.. IMHO this is all about, developing-style, or, habits.

With no intent to say a bad word about my friend (He is a great friend and good partner), I had a big discussion like this with him, and he is a spring user, and use it at his company. When we talk about the stack and tachnology will we used in our freelance project, He still argue that we need a lightweight container (tomcat/jetty). But I prefer that Java EE, with argumenting about a lot of vendor support if client doesn't satisfied with our service, and more adoption in the future (in the community) to help us developing the application.

At the end of discussion, we both agree that we doesn't familiar with the framework programming model. I know spring and use it in simple example project (just for my CV that show if I 'can' use Spring), but I never used it in real-project where I using Seam intensively.

On the other side, my friend tell me with honestly that he also doesn't familiar with the Java EE 6 programming model. Of course, like me, he had playing with seam just for proof that he 'can' use Seam.

Finally, in my case 'vendor support' win for the client benefits. In the case of Java EE may disappointed both of us in some area of stage (design, development, production, maintenance, upgrade version, blablabla) and we can't satisfied the client, we agree that at least they know oracle/IBM (Sorry, but at least in my country, RedHat/JBoss is as strange as VMWare/Springsource in client point of view). Call me stupid, but this is our (me and my friend) decision :D.

@David. Sorry if out of topic a bit. Please don't delete my post :D. Im not a representative of primefaces nor start another 'war', but I'm just curious about PrimeFaces is too weak for what I need.. Can you describe it more? I just planning to use primefaces and love a some advice from you about this. Thanks.

 
10. Jan 2010, 01:11 CET | Link
esbium
Poor Gavin is fighting an uphill battle and he knows it, thats why he is hiding behind the JEE 6 "Standard" to promote JBoss. Gavin, you keep talking about "Standards" and my question to you is, whats the difference between a Standard in your terms and a De Facto/Industry Standard? I mean, your own personal project Hibernate became an Industry Standard and you still point to the JEE 6 Standard as being what everyone should adopt/eventually move to. What value does the word "Standard" really have anymore? In a world of thousands of open source projects, many with huge followings, does a Standard really matter?

Talking out both sides of my mouth, without the Servlet Standard, we would be stuck running our apps in all different kinds of servers so I am not saying I don't see some value in standards. However, saying "The Standard" really doesn't mean as much as it used to. To me, Spring + Hibernate is a Standard. I don't care if there is no official body behind that "Standard", its an Industry/De Facto/Whatever Standard!

/rant

 
10. Jan 2010, 02:30 CET | Link
Poor Gavin is fighting an uphill battle and he knows it

The community reaction to CDI and EE6 says otherwise. And the big blip in web traffic on http://seamframework.org and http://in.relation.to since CDI went final definitely says otherwise. Do you realize that this blog gets almost as much traffic as news sites like InfoQ?

Anyhow, battle is just not the right word. At some level I don't really care which platform is most popular. I care which is better, technically. :-)

thats why he is hiding behind the JEE 6 "Standard" to promote JBoss.

Oh yeah, that's right. I don't actually believe anything I write about the value of standards, I'm just using it as a foil to try and trick you all into using JBoss AS. This despite the fact that I have dedicated the last 5 years of my life to improving the Java standards, and have never actually worked on JBoss AS.

I mean, your own personal project Hibernate became an Industry Standard and you still point to the JEE 6 Standard as being what everyone should adopt/eventually move to.

Oh what a hypocrite I am!

Mr. Esbium, sir, you're an idiot, and a rude one at that. I would delete your post, but I'm going to leave it here as a fossilized evidence of your idiocy and lack of basic respect for people you disagree with.

 
10. Jan 2010, 04:11 CET | Link
Sakuraba | saku(AT)raba.jp

Okay I get it. JEE6 is not EJB2 and app-servers are no longer bloated (in my last EJB3/JBoss project it took 30 seconds to actually see a change I made in my sources). I get all of that.

But the one thing I dont understand is: What do I gain from switching a Spring/Hibernate app to a CDI/Weld/Hibernate app? What do I gain from that while keeping in mind that personally I do not care about standards/appserver-portability/etc?

 
10. Jan 2010, 05:41 CET | Link
What do I gain from switching a Spring/Hibernate app to a CDI/Weld/Hibernate app?

Well, personally I think the JPA API is much cleaner, more elegant, and has better-specified behavior than the Hibernate API was before the advent of JPA. When we wrote the JPA spec, it was an opportunity for me to really nail down a lot of the semantics of Hibernate that had previously been underspecified, and correct certain errors. That's the advantage of having a whole expert group write a specification in words, rather than having a couple of guys write some code and then toss it out there. Even though you're not using the JPA APIs, you are benefiting from the work of the JPA expert group did in nailing down the right behavior for a JPA implementation. Trust me, the JPA EG did a much, much better job of characterizing this behavior than I did in the old Hibernate docs. Yes, the semantics of most of the operations were based on Hibernate's semantics, but the EG forced me to really think through all the corner cases and best defaults.

Likewise, IMO, CDI is cleaner, more elegant, and easier to use than Spring. CDI has a smaller number of constructs, but is at least as powerful as the Spring core. CDI guides users down a path where application code is easier to read, more typesafe and less vulnerable to errors that could have been checked by the compiler or tooling. Like JPA, CDI went through a huge amount of review by many people from different backgrounds in the Java community, and there's virtually no behavior in the spec that has not been discussed to death, and undergone review by a bunch of eyeballs.

Even better CDI is the foundation of an ecosystem of portable extensions that eventually all CDI users will benefit from. Third-parties can build on CDI with the confidence that their extensions will integrate with zero user-effort in any environment that supports CDI. All the user has to do is throw the third-party jar in the classpath.

Now it's over to you Sakuraba. The rest is your responsibility. Have you actually tried out CDI? Or do you just keep posting stuff in blog comments while choosing to remain ignorant of what CDI has to offer?

 
10. Jan 2010, 06:18 CET | Link
Darryl Smith

Any plans on Weld implementing something like Spring's TestContext Framework

Some mentions of @RunWith(EmbeddableEJB3Runner.class) where mentioned here

 
10. Jan 2010, 07:17 CET | Link
henady
i am using ee5+seam+jpa+jsf in project. why should i upgrade to ee6 ? only because there is weld instead of seam and singleton antipattern is added to EJB?

jsf2 does not solve any of jsf problems. i can describe.

1. any jsf page requires a websession to keep component tree (why this is not configurable?).
2. if this is ok, try submit after 1h. for example try to login to this blog after 1h. you will see
Your session has timed out, you have been redirected to the start page.
and redirect to http://in.relation.to/wiki.seam?cid=1205656
3. jsf spends lots of memory. see UIComponentBase saveState/restoreState for details.
4. jsf2 components libraries are not ready and when they will be ready i suppose that they will still render ugly html code with tons of dependencies. web-desing applying is hard because css and code generation are inside java/jars. Often there are prototypejs and jQuery mess with dups of functionality. select 'view source' in browsers menu and you'll see.
5. component developing is still not easy. try render h:selectOneRadio in 2 columns. you'll need for java render.
6. jsf is simple slow. i used wicket, it is subjective faster.

jsf is a standard. it is sad, because other web frameworks began stagnate. ee6 is the next step to propagate this bad solution. only things i like in jsf are facelets and EL.


ee6 still forces using of ears/wars with tons of /lib/*.jar inside. If i do not want use jsf should i put 20 megs of tapestry to /WEB-INF/lib folder? oh no. and how i will use tapestry with weld? what's new in ee6 then?

are ears still starting in alphabetical order? i need for dependencies between ears without editing xmls in app server.

shared ee6 hosting like PHP shared hosting. does someone believe in this?

for me SpringSource dm Server is much more innovate and interesting than ee6. weld\seam is innovate, but is it only the reason to switch to ee6 ? especially for people that do not plan use jsf.
 
10. Jan 2010, 07:29 CET | Link

Erm, Java EE 6 and Weld work great with Wicket. If you prefer Wicket to JSF, then use Wicket.

 
10. Jan 2010, 07:30 CET | Link

We're already working on a test harness as part of the Seam (3) project.

 
10. Jan 2010, 23:54 CET | Link
Guy C

My humble opinion: - If you are already using Spring so be it. No point wasting time when you can add more value such as adding features to your existing projects. - If you are considering Spring or JEE 6.0 for a new project and the former is more familiar to you, please continue to use Spring. I rather stick to a technology/framework/whatver that my team is familiar with instead of trying the latest and greatest. - If you are considering Spring or JEE 6.0 for a new project and you have all the time in the world, please go write some code and try JEE 6.0 out instead of arguing with Gavin the merits of Spring on his blog (it is like going to a house uninvited and criticizing the decor of his apartment). Make your own decision and live with it. - For everything else, please continue to post here. My Link

P.S. Gavin, is your blog intentionally sending comment postings as RSS feeds? I am getting all these comments via Google Reader and I am more interested in reading your blog postings instead of all these.

 
11. Jan 2010, 04:49 CET | Link
Arbi Sookazian

Not sure how much clout Forrester research has, but...

Forrester projects a bright future for application frameworks that are outside the traditional .NET and Java EE spheres of influence. The firm expects Flex, Tomcat, Dojo, Drupal, GWT, JBoss, Ruby on Rails, Spring and Zend to gain traction. In applying such software, teams will use a fit-to-purpose approach. “The organization will define multiple ‘good enough’ platforms, each optimized for different application scenarios,” according to the Forrester authors.

http://www.theserverside.com/news/thread.tss?thread_id=59117

The challenge with the frankenstein or hodge-podge stack approach (as opposed to one vendor one-stop-shop Microsoft approach) is production support. The advantage with EAP support from JBoss is that you'll get high-quality support for JBoss AS (EAP), Hibernate, RichFaces, Seam, etc. But that's if and only if you don't deviate from their tech stack.

But what if you go the GWT+Spring route or Wicket+EE6/Seam3 route in terms of support?

 
11. Jan 2010, 15:20 CET | Link
Alberto Gori
henady wrote on Jan 10, 2010 01:17:
jsf2 does not solve any of jsf problems. i can describe. 1. any jsf page requires a websession to keep component tree (why this is not configurable?).

You can still choose between state on session and state on client (rendering the state in a input hidden field).

2. if this is ok, try submit after 1h. for example try to login to this blog after 1h. you will see

This is not a problem. If you don't want this behavior, you can poll the server before the session timeout. It's quite easy to write this piece of code.

3. jsf spends lots of memory. see UIComponentBase saveState/restoreState for details.

I think JSF2 introduces some news about state saving. I think now JSF saves only a delta of the state change.

4. jsf2 components libraries are not ready and when they will be ready i suppose that they will still render ugly html code with tons of dependencies. web-desing applying is hard because css and code generation are inside java/jars. Often there are prototypejs and jQuery mess with dups of functionality. select 'view source' in browsers menu and you'll see.

Tons of dependency? Waht do you mean? Web designing is not hard, thanks to CSS2-3. Facelets is the new standard, and is more easy to write and modify your component.

5. component developing is still not easy. try render h:selectOneRadio in 2 columns. you'll need for java render.

No, you need the Tomahawk version of selectOneRadio. There is a component for almost everything in JSF.

6. jsf is simple slow. i used wicket, it is subjective faster.

It was clear to me, also before reading the point 6, that you are a Wicket fan. Anyway I don't think you tried JSF 2.0.

jsf is a standard. it is sad, because other web frameworks began stagnate.

JSF is a great framework. 2.0 introduces a lot of news. How can you say that it's stagnate? Oh yes, you are a Wicket fanatic. Wicket fanatics are very similar to Spring ones.

 
11. Jan 2010, 23:10 CET | Link

Folks,

Like all people, Gavin is not perfect. However, one thing I've personally grown to understand is that he is sincere about his commitment to Java EE and does not do things simply as a way to advance JBoss. Questioning his motives is very narrow-minded IMO. For one, he could have gone the route of not standardizing Hibernate, not to mention Seam.

Good job Gavin!

Cheers, Reza

 
12. Jan 2010, 02:06 CET | Link
Paul Mooney | paul.mooney(AT)live.com
Oh yes, you are a Wicket fanatic. Wicket fanatics are very similar to Spring ones.

That sounds like a flame war comment.

And I think that comment is also completely wrong. People (or fanatics) who prefer Wicket, and Java EE, like to program in Java! People who prefer JSF like, or settle for, a lot of programming in xml which is very similar to Spring.

I'm not bashing JSF, it's great with all of its component libraries (I hope they work together in JSF 2!), and its xml approach can be shorthand compared to Wicket, at least at first. I'm just pointing out how Wicket aligns better with Java EE mentality of less xml and convention over configuration.

I don't really see how there's a comparison between these fanatic groups

 
12. Jan 2010, 08:00 CET | Link
You can still choose between state on session and state on client (rendering the state in a input hidden field). .... Anyway I don't think you tried JSF 2.0.

i tried 2.0. i downloaded glassfish3 and javaee6-samples-1.0-b03-installer.jar 10 days ago. I think that you have never seen client side state method, so here is a screen for you: JSF2 client side state saving . It is from standard scrumtoys example from Ed Burns and Co. written in jsf2 and run on glassfish. i changed only server to client STATE_SAVING_METHOD parameter in web.xml. 2300 bytes for 7 links, one empty combo and button. And note that there are 2 forms on the page. You can download sample and check by yourself. let me know if you need for direct link to javaee6-samples-1.0-b03-installer.jar

I think JSF2 introduces some news about state saving. I think now JSF saves only a delta of the state change.

delta between what and what? i did not found changes in scrumtoys.

This is not a problem. If you don't want this behavior, you can poll the server before the session timeout. It's quite easy to write this piece of code.

do you mean javascript setInterval(...) ? I know this method. This is a hack. And if you already logged in then you will need for other script. Hmmm, consider that php, ruby or python cannot work without session in web. but jsf really cannot. forget about client side save method.

also i know other decision: usage of another servlet than FacesServlet for stateless forms. nice.

oh yes. code from scrumtoyss web.xml

    <error-page>
        <exception-type>javax.faces.application.ViewExpiredException</exception-type>
        <location>/index.html</location>
    </error-page>
Tons of dependency? Waht do you mean?

I wrote. I just forecast, time will show. jsf2 is new thing.

Oh yes, you are a Wicket fanatic. Wicket fanatics are very similar to Spring ones.

thanks. It is not a shame to be a fanatic of things that helps do something useful. In fact, Wicket uses java class behind every html, it is not flexible, so i am not wicket fanatic. But you can call me wicket or spring fanatic, i like it.

JSF is a great framework.

good idea, but bad implementation. it's seems because of JSP support. maybe apache myfaces will make something better than mojarra, i still hope.

 
12. Jan 2010, 15:17 CET | Link
Alberto Gori
henady wrote on Jan 12, 2010 02:00:
i tried 2.0. i downloaded glassfish3 and javaee6-samples-1.0-b03-installer.jar 10 days ago. I think that you have never seen client side state method,

I have seen and used it and I am aware of its limitations. But it's there and works.

so here is a screen for you: JSF2 client side state saving . It is from standard scrumtoys example from Ed Burns and Co. written in jsf2 and run on glassfish. i changed only server to client STATE_SAVING_METHOD parameter in web.xml. 2300 bytes for 7 links, one empty combo and button. And note that there are 2 forms on the page. You can download sample and check by yourself. let me know if you need for direct link to javaee6-samples-1.0-b03-installer.jar

You have to minimize your components tree if you use this state. Really Wicket is the same with and without an HttpSession? I think you have to be carefull in JSF and in Wicket.

do you mean javascript setInterval(...) ?

No, I mean use a4j:poll or something like that. One like of xhml.

JSF is a great framework.
good idea, but bad implementation. it's seems because of JSP support. maybe apache myfaces will make something better than mojarra, i still hope.

JSP is deprecated. In 2010 we use Facelets that solves every JSP issue and is a very elegant and flexible tool with convention over configuration philosophy.

 
13. Jan 2010, 04:58 CET | Link
Arbi Sookazian

What is the solution for avoiding Hibernate LazyInitializationExceptions in JEE6 and Spring 3? In Seam 2.x we use Seam-managed persistence context (SMPC) with Hibernate manual flush (if Hibernate is your persitence provider) and it works well to keep the persistence context open for the duration of a long-running conversation, for example, and thus no detached entities to worry about causing LIEs when the relations are navigated in a JSF view.

The Spring solution was filters and Open session in view (OSIV) last I heard...

 
13. Jan 2010, 14:08 CET | Link
Arbi Sookazian wrote on Jan 12, 2010 22:58:
What is the solution for avoiding Hibernate LazyInitializationExceptions in JEE6 and Spring 3?

Probably a portable JCDIMPC for EE

PS.

Bill Shannon corrected Nik in a mail correspondance
But please, there is no JEE. Never use that name. Use Java EE, or if that's too much to type, just EE
 
13. Jan 2010, 15:08 CET | Link
Grzegorz Grzybek | gr.grzybek(AT)gmail.com

What Seam3 provides is integration to other non-standard third-party technologies for those applications which want to go beyond the basic Java EE stack.

...

All of these things are perfect examples of things that could be CDI portable extensions. I'm not a fan of Spring Security or Spring WebFlow (I think Seam Security and jBPM are much superior), and I don't know anything much about Spring Integration or LDAP, but I'm sure that someone who is a fan of these technologies could easily do the work and integrate them with CDI via the SPI.

...

And I think that - with the exception of security - these technologies should probably stay in the realm of portable extensions. I don't think EE should include built-in orchestration or integration solutions. (I do think that EE needs a new spec for security, perhaps based along the lines of Seam Security.)

...

Even better CDI is the foundation of an ecosystem of portable extensions that eventually all CDI users will benefit from. Third-parties can build on CDI with the confidence that their extensions will integrate with zero user-effort in any environment that supports CDI. All the user has to do is throw the third-party jar in the classpath.

I understand and I can get a feeling of your job. You've created Hibernate and standarized it as JPA. You've created Seam and wanted to move the ideas born during its development to JavaEE. For you the future is a development environment, where every common functionality is provided as CDI extension, Java developers just pick the needed extensions and write JavaEE code based on CDI and supported by CDI extensions. Let's see how the future will look like. How many products will go the way of CDI SPI. I wonder if/when the market of CDI extensions will emerge.

But Seam3 is generally in planning stage (maybe some pre-alfa - but I might be wrong), and Spring Framework is already a foundation of existing products (e.g. ActiveMQ). If until recently there was no real (technical) battle between Spring and JavaEE (Spring makes JavaEE easier), now it has already started.

Right, so what were you complaining about, again?

Maybe this discussion and my comments became boring, but I just want to be clear and leave the thread with some clear thoughts/complaints/opinions.

You should upgrade to Java EE 6
Let me just note that what Java really needs is a decent built-in modularity solution.

That's not about Spring XML vs. CDI. That's about the main point of your post.

JavaEE's main succes (IMO) was to put Java packaging to a higher level with WARs and EARs (initially) and other packaging formats. However - these have not changed much since J2EE. JSR-291 is for JavaSE (at least that's what the name of the JSR says) and JSR-294 and JSR-277 (jigsaw) were marked inactive.

I wonder why JavaEE 6 doesn't include any significant changes regarding packaging. EARs/WARs/RARs are ok, but what about MANIFEST.MF? What about OSGi (JSR-291)? Even Glassfish v3 is based on this component model.

For me there are two kinds of modularity in Java - static/deployment and dynamic/runtime. The former is (quite) succesfully handled with tools such as Maven or Ivy (of course with their own problems), and the latter is a domain of OSGi.

I think one of the arguments against SpringSource was that their DM Server (since yesterday under Eclipse RT umbrella and EPL licence) was against JavaEE. I don't have much experience with this product, but it sure is innovative and created because of the interest in OSGi. Do you think integrating JavaEE and OSGi is a good idea?

Likewise, IMO, CDI is cleaner, more elegant, and easier to use than Spring. CDI has a smaller number of constructs, but is at least as powerful as the Spring core.

And finally - good you've mentioned it's about Spring core and not Spring. I try to write comments in various posts where someone compares e.g. CDI to Spring, that XYZ is better/easier/more lightweight than Spring. This discourage people against Spring in general. Spring is now a portfolio of many different products - some with more competition, some with less. CDI is generally just an (ok, more type-safe, sometimes easier, sometimes more elegant) equivalent of SpringFrameworks's DI container. Just don't compare it to Spring.

I'm not a fan of Spring Security or Spring WebFlow (I think Seam Security and jBPM are much superior), and I don't know anything much about Spring Integration or LDAP, but I'm sure that someone who is a fan of these technologies could easily do the work and integrate them with CDI via the SPI.

Now you're talking about products, not Spring. I understand, because I don't know Seam Security and jBPM - I just get accustomed with Spring's equivalents. Though I think jBPM's role is different than Spring WebFlow. And about integrating it with CDI via SPI - will see. I personally would like to see an experiment of making SpringFramework's DI compatible with CDI - just as an option for those who think that Java EE has all the functionality now that the old J2EE + Spring can supply..

Upgrading the EE application server is "hard"

In other three myths you are generally right. Maybe less right with the fourth - it's easier to port an application if more dependencies are part of your application. I don't rely on JPA in JBoss - I include a version of Hibernate I want in my WAR. Maybe that's why significant percentage of developers choose Spring's component model - they've became independent of application server (at least within this aspect). And about upgrading - sometimes it's really hard because it is not cheap or using open source server is not politically correct in organizations where some vendor gives extra bonuses along with licences.

 
14. Jan 2010, 04:56 CET | Link

J2EE did suck before 2005 but from what I've experienced with SEAM, EJB3.0/JPA,(even JSF1.2 but only with SEAM) and from what I'm reading about JSF2/ CDI, I know JEE6 is going to be awesome. It's too bad that it's gonna be hard to convince chumpers from most employers to abandon some very non-standard crappy archs and move towards this joy. Everytime I try to advocate I get angry retaliation. I've yet to get the chance to work with truly great technology at work. The only times I get to write with true joy is on my own pet projects

 
14. Jan 2010, 06:47 CET | Link

I think Spring folks like to write code in XML heehee

 
14. Jan 2010, 06:59 CET | Link
nepoez
To be honest, When I was moving from .NET to the JAVA world, the amount of "code" written is XML but labelled as "configuration" made me really resist all the JAVA frameworks out there. It's only until Seam that I truly enjoyed written web apps. Annotate my beans and feeling that that's where the "config" belongs" Injecting things here and there where it most make sense instead of writing 5 other XML files just to get something simple to work..

<blockquote>
_Gavin King wrote on Jan 08, 2010 17:51:_<br/>

"There is nothing to discuss about. I know I can choose between |<entry key="x" ref="y" />| and |map.put("x", y)|. I chose XML because for me that's configuration, not code. If I was a Ruby programmer, I could choose YAML, for JavaScript I could use JSON and so on. For Java I chose XML where it fits."

I hope you now see that you "chose XML" because that is what Spring encourages and because that is what you're used to. Not because it's the only way to solve the problem, or even the best way to solve the problem.

CDI is not Spring. The folks who created CDI are not Spring fans. Most of us think that the fashion for programming in XML is a bad thing that has led to a mountain of code that is difficult to understand, refactor and maintain (by humans, and tools). It's led to a crazy mindset where just about anything might be considered "configuration", even if it never actually changes between deployments of the system. It's a disease particular to the Java community. Programmers outside of the Java community *don't* do things this way. They aren't addicted to configuration, and to splitting their code between two languages.

So when you approach CDI, you need to take a step back from your "this is how I do it in Spring" worldview and explore a *different* way to do it, which uses plain, typesafe Java code.
</blockquote>

Click HELP for text formatting instructions. Then edit this text and check the preview.
 
14. Jan 2010, 10:35 CET | Link

With all due respect to CDI , I wish people would stop this Spring is XMl talk. I have built and currently manage a few hundred thousands lines JEE app built on Spring, And our XML is bare minimal (less than 100 lines in all).After Annotation driven injection introduced in Spring 2.5 (and its been almost 2 years since it has been around), the whole argument of Spring is XML does'nt hold any more. If anything we have more xml in our hbm files (we did not go the JPA route since JPA1.0 was less functional API compared to Hibernate as such) and frankly thats not big of an issue.

I guess CDI provides better DI constructs and better type safety (I am yet to try it out) but frankly the whole Spring is XML argument does'nt really hold any longer.

 
14. Jan 2010, 15:28 CET | Link
Alberto Gori
Satish wrote on Jan 14, 2010 04:35:
With all due respect to CDI , I wish people would stop this Spring is XMl talk. I have built and currently manage a few hundred thousands lines JEE app built on Spring, And our XML is bare minimal (less than 100 lines in all).After Annotation driven injection introduced in Spring 2.5 (and its been almost 2 years since it has been around), the whole argument of Spring is XML does'nt hold any more. If anything we have more xml in our hbm files (we did not go the JPA route since JPA1.0 was less functional API compared to Hibernate as such) and frankly thats not big of an issue. I guess CDI provides better DI constructs and better type safety (I am yet to try it out) but frankly the whole Spring is XML argument does'nt really hold any longer.

Last time I was interested in Spring was because of Orchestra. It's a MyFaces extension with annotation introducing features like conversation, direct jpa support. In few words it's a very simplified Seam like project based on Spring instead of EJB.

This is the required XML:

http://myfaces.apache.org/orchestra/myfaces-orchestra-core/installation.html

I asked about reducing this XML (note that <tx:annotation-driven/> is already used), but they answered that this for many reasons was not possible, or hard to do.

Do you still think that Spring is not that different from CDI? I don't know about Spring3.

 
14. Jan 2010, 16:50 CET | Link
Alberto Gori
Satish wrote on Jan 14, 2010 04:35:
If anything we have more xml in our hbm files (we did not go the JPA route since JPA1.0 was less functional API compared to Hibernate as such) and frankly thats not big of an issue.

Do you know Hibernate annotations? Mixing standard JPA annotation and Hibernate ones you can achieve almost every functionality you have in hbm files.

17. Jan 2010, 18:05 CET | Link
Marc Schipperheyn

I have read a few of these J2EE vs Spring posts and although they are amusing to read in a Jerry Springer kind of way, I just want to say that no-one should have to take this much crap for giving the community all this great technology for free (any crap at all for that matter). While I'm a Spring user currently I benefit daily from Gavin's excellent work. Hat of to you, sir. And keep it up.

Cheers,

Marc

27. Jan 2010, 06:50 CET | Link
cng

Does CDI have any support for injecting dependencies into objects constructed by the application.. How do we inject dependencies into the Command objects if we use the command pattern (we would have to manually construct these objects since they have runtime state initialized at construction time).. (In spring, we would use the @Configurable annotation along with aspect weaving)

27. Jan 2010, 12:14 CET | Link
Does CDI have any support for injecting dependencies into objects constructed by the application

Use BeanManager.createInjectionTarget().

 
05. Feb 2010, 12:44 CET | Link
Arbi Sookazian

I have brought up the subject of experimenting with and eventually migrating to JBoss 6 with my current company's chief architect and architect. The architecture team is very conservative, esp. when you're dealing with apps that move people's money around (payment processing with card and check). So Spring 3 and Java EE 6 are not currently recommended or on the road map.

How do we as Java EE developers currently using JBoss 4.2.x (Java EE 5 platform) go about convincing staff and management to start using bleeding-edge libraries like JSF 2, JPA 2, CDI/Weld, etc. on our current or future projects? It seems that big Fortune 500 kind of companies are usually 1-2 years behind in terms of adoption and production deployments.

Their stance is that there was/is minimal adoption of Java EE 5 and that EJB 3 is not backwards-compatible which is not true.

Money savings and performace and productivity boosts (and lower maintenance costs) are good sellers for new technology. How does Java EE 6 fit the bill in this respect? We are currently using JBoss 4.2, Seam 2.1, JPA 1.0, Hibernate 3, JSF 1.2, Facelets 1.x, Richfaces 3, Maven 2.

For example, have there been any changes or optimizations in the JSF lifecycle to speed up performance? Typically getter methods are executed multiple times (seemingly too many times) during a request/response cycle. There have been documented performance problems with JSF 1.2 and Seam 2.x:

http://www.jsfcentral.com/articles/speed_up_your_jsf_app_1.html

 
05. Feb 2010, 12:49 CET | Link
Arbi Sookazian

btw, I substituted the Mojarra 2.0.2 jsf-api.jar and jsf-impl.jar into the \server\default\deploy\jboss-web.deployer\jsf-libs directory and did not have any issues with my Seam 2.1.1.GA app in terms of backwards-compatibility after executing several test cases.

 
09. Feb 2010, 18:04 CET | Link

We would love to upgrade to Java EE 6, but here is our problem, we run JBoss EAP in production. Now, how long did it take for JBoss EAP 5 to come out. How long do we have to wait for JBoss EAP 6? We cannot use Java EE 6 because that is not supported in the current EAP 5 version.

 
06. Mar 2010, 00:25 CET | Link
Rafa

Gavin, please, stop spreading FUD... it's enough. Everyone knows that you don't know Spring, actually. Stop wasting time doing all that and make progress by studying spring framework or by reading some books about good code (instead writing bad code as you did in hibernate), what do you think? Are you getting paid (by JBo... err... some company) to spreading FUD? :) You are good at that (like Reza)! You (and Reza) should think about changing your caree... :)

 
06. Mar 2010, 00:43 CET | Link
Gavin, please, stop spreading FUD.

Where FUD = opinions you disagree with?

So I shouldn't express my own opinion in the comments thread on my own blog? What kind of a sick totalitarian mind do you have?

Everyone knows that you don't know Spring, actually.

Where Everyone = you and who else?

If I know so little about Spring, then you must be able to point to all kinds of technically incorrect claims I make about Spring. So why not respond to and correct these false statements instead of criticizing me personally?

Actually, everyone knows that resort to ad hominem implies that you don't really have any good technical arguments.

Stop wasting time doing all that and make progress by studying spring framework or by reading some books

Out of interest, exactly how much time have you spent studing CDI and Java EE 6? Have you read the Weld documentation and the CDI spec. Or is it in fact you rather than me who needs to do their homework?

instead writing bad code as you did in hibernate

Hehe, I hope I get a chance to write some more code as bad as Hibernate one day. :-)

Are you getting paid (by JBo... err... some company) to spreading FUD?

Of course! There's absolutely no possibility that I actually believe the things I write. In fact, it's a fair assumption that everyone who ever disagrees with your view about anything is some kind of shill and is insincere in their beliefs.

Mr Rafa, sir, you've really got some growing up to do if diversity of opinion bothers you this much, and if this is your idea of constructive contribution to a technical debate.

 
16. Mar 2010, 05:55 CET | Link
mukul

Maybe wrong thread but couldnt find a recent thread to ask: Is there any comparative analysis of the JBoss framework stack (Seam, Hibernate) vs Oracle ADF available or if you remember even seeing one at some time in the past?

 
24. Nov 2014, 11:55 CET | Link

Hmm it seems like your site ate my first comment (it was extremely long) so I guess I'll just sum it up what I wrote and say, I'm thoroughly enjoying your blog. I as well am an aspiring blog writer but I'm still new to the whole thing. Do you have any helpful hints for beginner blog writers? I'd genuinely appreciate it. Brain Stimulator Review