JSR 244 - the Java EE 5 specification - has passed unanimously (and, judging from the ballots, rather joyously as well.) This means the specifications under it - JSF 1.2, JSP 2.1, EJB 3.0, JAX-WS, and other specifications - are all set to go, even if the implementations aren't ready for prime time. This clears the way for application server vendors to announce compatibility and support - and means developers can use the new programming models.

Congratulations are in order for the expert group members involved in the set of specifications involved, and this indeed can open the floodgates on the simpler development models in Java EE. Now we get to see how Spring reacts to stay ahead. :)

Congratulations !

Looks like Sun is ready to release Glassfish and NetBeans 5.5 soon.

But what is about Tomcat? It used to be the reference implementation of a servlet container.

Nebojsa

I've been reading through the tomcat and myfaces mailing lists a bit, but both Apache projects don't really seem to have much incentive to rush into the Java EE 5 specs. Contrary to Hibernate who followed the spec-in-development pretty closely, MyFaces seemed to be more concerned with getting their 1.1.2 bug fix release out of the door and creating more stuff for their value added project Tomahawk.

I wonder whether anyone has any idea when the EE 5 web tier will be fully covered by the Tomcat 6/MyFaces 1.2 combination. Of course, both the JSP and JSF specs don't differ that much from their previous versions, but seeing that Tomcat and Myfaces haven't even started it'll probably not be anytime soon.

I wonder whether anyone has any idea when the EE 5 web tier will be fully covered by the Tomcat 6/MyFaces 1.2 combination. Of course, both the JSP and JSF specs don't differ that much from their previous versions, but seeing that Tomcat and Myfaces haven't even started it'll probably not be anytime soon.

I know work on Tomcat to cover the latest specs has been underway for some time.

Unfortunately, it does not appear that Tomcat will support the new specs all but immediately as in the past, which is unfortunate. That's not the Tomcat guys fault as I see it, but rather Sun's for putting a lot more emphasis on an end-to-end Java EE5 reference implementation than the part that is of the most immediate practical use -- a rock solid servlet engine (Tomcat) to support the servlet/JSP portions of the spec in a standalone fashion.

That said, those of us forced to support other servlet engines can't leverage any nice new spec features if they appeared in Tomcat today -- as we have to wait aeons for the pricey, but ever so slow commercial vendors to support the spec, which won't be for a long, long time...

...
That's not the Tomcat guys fault as I see it, but rather Sun's for putting a lot more emphasis on an end-to-end Java EE5 reference implementation than the part that is of the most immediate practical use -- a rock solid servlet engine (Tomcat) to support the servlet/JSP portions of the spec in a standalone fashion.That said, those of us forced to support other servlet engines can't leverage any nice new spec features if they appeared in Tomcat today -- as we have to wait aeons for the pricey, but ever so slow commercial vendors to support the spec, which won't be for a long, long time...

Really? Tomcat is reference implementation of servlets and JSP. So I don't know what are you balbbering about...

> Tomcat is reference implementation of servlets and JSP.That was true in the past, but it is not the case for the latest Specifications. The reference implementation is based on the Open Source GlassFish code base.

This is smart on Sun's part in that their reference implementation is more closely aligned with their own offerings and raises the chance that their offerings will track the spec better than their competitors. It's also good that they can immediately provide an end-to-end reference implementation of the entirety of Java EE 5.

Unfortunately, it's also bad for many of us in that it means the only way to tightly track the spec is to go to a heavy app server rather than stick with the lightweight servlet engine we know and love (Tomcat). The loss of Sun's backing that is an integral part of being the reference implementation will also mean Tomcat will no longer be on the cutting edge of the specs. This fits right in with Sun and other app server vendors play to push the complex all-inclusive app server option and ignore lighter options like standalone servlet engines.

That said I suspect Tomcat will still have quality support for the latest specs prior to many commercial vendors. For instance, Sun's own servlet-engine-only product, which still does not support the servlet 2.4 and JSP 2.0 options (unless they just released this), seems likely to lag by a bit. The version of WebSphere that officially supports Java 5 is also not out yet -- or just out if it is.

It is possible to take Grizzly (the NIO-based connector) and the Servlet & JSP pieces of GlassFish and make a stand-alone servlet/JSP engine. Our goal, though, is to make the whole thing modular so that you get the best of both worlds. We think we can do it, if we stay focused, but a standalone Web-tier artifact is certainly possible.

It would be great if this was more than "possible" and something one *could* do. Rather it would be much better to have a clearly documented ready-to-use standalone servlet/JSP engine module.

Not any more. Now Glassfish is the reference implementation, and also the basis for the production quality Sun App Server 9, and also the basis for the Java EE SDK, which can be downloaded from http://java.sun.com/javaee/5.

Ed Burns (JSF co-spec lead)

Well folks, if you have not looked in a while it is worth taking a re-look at the specification. There is a reason why Tomcat is no longer the reference implementation of JSP's and servlets. Because of the resource injection engine for JNDI Objects based on the meta-data tags that can reside in the Servley/jsp code, Glassfish J2EE is the reference implementation of the JSP's and servlets. This server does not start as quickly as Tomcat, but you will find it as functional, and easier to administer, through the Glassfish admin console. Besides, for the speed freaks, because glassfish uses the the Java NIO (New Non-blocking IO) the service engine is faster. I believe the code has been given back to Apache to re-integrate. Basically, it is a great web container for standard war files.

Of course, both the JSP and JSF specs don't differ that much from their previous versions, but seeing that Tomcat and Myfaces haven't even started it'll probably not be anytime soon.

MyFaces will be branching for 1.2 very soon, so hide your women and children.

Most of the difficult changes in the 1.1 implementation ( the "back button" problem, client side encryption ) have been completed. Stan Silvert has knocked out a handful of others but we cannot commit this stuff because it may break 1.1 TCK compliance tests.

Of course, both the JSP and JSF specs don't differ that much from their previous versions, but seeing that Tomcat and Myfaces haven't even started it'll probably not be anytime soon.

MyFaces will be branching for 1.2 very soon, so hide your women and children. Most of the difficult changes in the 1.1 implementation ( the "back button" problem, client side encryption ) have been completed. Stan Silvert has knocked out a handful of others but we cannot commit this stuff because it may break 1.1 TCK compliance tests.

Besides that to my knowledge J2EE5 requires JSF 1.1, unless things have changed.
The rest is out of the scope of MyFaces (EJB, JPA etc... are entirely different issues)

Congratulations !Looks like Sun is ready to release Glassfish and NetBeans 5.5 soon.But what is about Tomcat? It used to be the reference implementation of a servlet container.Nebojsa

I don't know, but the Apache Software Foundation voted yes, so they are ok with it.

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

Any new about Apache Geronimo, how long it takes to accomodates to JEE5 ?

Any news/idea about Apache Geronimo, how long it takes to accomodate JEE5 ? It has a Great Architecure, and now IBM is behind Geronimo, looking forward to that....

Any news/idea about Apache Geronimo, how long it takes to accomodate JEE5 ? It has a Great Architecure, and now IBM is behind Geronimo, looking forward to that....

I'm also curious what persistence framework / ORM will Geronimo use?
IMO this is the most important element of Java EE 5 for enterprise applications.

Glassfish's ORM is based on Toplink. Sounds very promising.

http://www.enterpriseware.eu

According to sources, BEA is donating OpenJPA to the Geronimo project, so there would be your default container. OpenJPA isn't ready yet - not that I know of, and BEA's site didn't say it was - but I can't imagine it'd be that far off.

According to sources, BEA is donating OpenJPA to the Geronimo project, so there would be your default container. OpenJPA isn't ready yet - not that I know of, and BEA's site didn't say it was - but I can't imagine it'd be that far off.

Yes, Open JPA has been accepted by the Apache Incubator, and the basic infrastructure for the project has been created. We're now just waiting on the code drops from BEA. Darn exciting, if you ask me.

Also, one of the nice things about the they-swore-it-wasn't-possible-to-do architecture of EJB3 is that user will be able to switch-even-though-certain-EG-members-said-it-couldn't-be-done between implementations of JPA, so one could swap in the open-source JPA engine from Glassfish if you wanted to try it...

:)

geir

Hi Geir.

> so one could swap in the open-source JPA engine from Glassfish if you
> wanted to try it...

We want to ensure that the GF JPA implementation works with all the other containers that support JPA and we are working on that right now, so send us a pointer when you think Geronimo is ready.

Thanks,
   - eduard/o

According to sources, BEA is donating OpenJPA to the Geronimo project, so there would be your default container. OpenJPA isn't ready yet - not that I know of, and BEA's site didn't say it was - but I can't imagine it'd be that far off.

Yes, Open JPA has been accepted by the Apache Incubator, and the basic infrastructure for the project has been created. We're now just waiting on the code drops from BEA. Darn exciting, if you ask me.Also, one of the nice things about the they-swore-it-wasn't-possible-to-do architecture of EJB3 is that user will be able to switch-even-though-certain-EG-members-said-it-couldn't-be-done between implementations of JPA, so one could swap in the open-source JPA engine from Glassfish if you wanted to try it...:)geir

I am not very happy with EJB3, but hearing about OpenJPA (KODO based) being donated to Apache is a nice silver lining.

It is nice to see some OpenSource competition to Hibernate.

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

I am not very happy with EJB3, but hearing about OpenJPA (KODO based) being donated to Apache is a nice silver lining.It is nice to see some OpenSource competition to Hibernate.Rick Hightower (linked in),blogJSF, Spring, and Hibernate training and consulting

For sake of completeness it is important to note that KODO core runtime together with JPA implementation will be available as opensource. JDO implementation built on top of
KODO core runtime will not.
BEA gave no explaination for their choice and, recently, they have announced the delay of KODO 4 release, implementing JDO2 spec, to wait EJB3 approval.
I don't know if I am the only one who thinks at this as a precise strategy to discourage JDO use in favour of JPA.
Anyway, it is not nice to see.

Guido

According to sources, BEA is donating OpenJPA to the Geronimo project, so there would be your default container. OpenJPA isn't ready yet - not that I know of, and BEA's site didn't say it was - but I can't imagine it'd be that far off.

Yes, Open JPA has been accepted by the Apache Incubator, and the basic infrastructure for the project has been created. We're now just waiting on the code drops from BEA. Darn exciting, if you ask me.Also, one of the nice things about the they-swore-it-wasn't-possible-to-do architecture of EJB3 is that user will be able to switch-even-though-certain-EG-members-said-it-couldn't-be-done between implementations of JPA, so one could swap in the open-source JPA engine from Glassfish if you wanted to try it...:)geir

I am not very happy with EJB3, but hearing about OpenJPA (KODO based) being donated to Apache is a nice silver lining.It is nice to see some OpenSource competition to Hibernate.Rick Hightower (linked in),blogJSF, Spring, and Hibernate training and consulting

Add to that the reference implementation based on the Toplink core code. ;-)

Is there any site with a tutorial or extensive walkthrough of JEE 5 with Glassfish?

Regards,

Carlos

Try http://glassfish.dev.java.net

Is there any site with a tutorial or extensive walkthrough of JEE 5 with Glassfish?Regards,Carlos

I've listed a whole load of tutorials and other Java EE 5 resources here (most of them use GlassFish) :

http://blogs.sun.com/roller/page/theaquarium?entry=java_ee_5_learning_resources3

and more to come over the next couple of weeks.

- Rich
Sun Microsystems
http://blogs.sun.com/theaquarium

Just what I was looking for!

Thanks Rich

- Carlos

I haven't read the latest spec, so I'm hoping someone who has can shed some light. Is there some new feature or clarification on existing functionality in the latest spec that is critical? Tomcat5.5.x already covers the older spec, which in my bias opinion does what most webapps need.

historically, tomcat has been very good about implementing the specification, but servlet spec has been mature for a while now.

peter

I haven't read the latest spec, so I'm hoping someone who has can shed some light. Is there some new feature or clarification on existing functionality in the latest spec that is critical? Tomcat5.5.x already covers the older spec, which in my bias opinion does what most webapps need.historically, tomcat has been very good about implementing the specification, but servlet spec has been mature for a while now.

peter

It's mainly features. It's the first JEE spec that's really captured the use of annotations for resource injection, services, persistence, etc. If that doesn't do anything for you, the rest could be considered maintenance revs of the existing specs.

I haven't read the latest spec, so I'm hoping someone who has can shed some light. Is there some new feature or clarification on existing functionality in the latest spec that is critical? Tomcat5.5.x already covers the older spec, which in my bias opinion does what most webapps need.historically, tomcat has been very good about implementing the specification, but servlet spec has been mature for a while now.peter

It's mainly features. It's the first JEE spec that's really captured the use of annotations for resource injection, services, persistence, etc. If that doesn't do anything for you, the rest could be considered maintenance revs of the existing specs.

I think the original poster was talking about anything new in the Servlet/JSP specification, not JEE 5 as a whole. And I'd have to say it's a resounding no. There's a JavaWorld Article that discusses the changes in the Servlet spec:
  http://www.javaworld.com/javaworld/jw-01-2006/jw-0102-servlet.html

And HLS wrote a good summary of what hasn't changed but should have here:
  http://howardlewisship.com/blog/2006/01/servlet-25-wheres-regexp.html

Mosty it seems the new spec involves support for annotations and resource injection in Servlets etc. which seems pretty useless to me as the vast majority of applications will have 1-2 servlets deployed, and those are usually provided by some framework or other.

Meanwhile, we are still lacking things like regular expression URL matching, container-independent programmatic login and other things that would actually make life easier.

-Tim Fennell
Stripes: Because web development should just be easier

so it sounds like the new thing is annotations, but that isn't really critical. Regexp URL filtering has been requested hundreds of times, but the spec still doesn't have it. oh well.

peter

We just upgraded our WAS from 5.0 to 5.1 last week. In the mean time, we finally move from JDK1.3 to JDK1.4 officially. And we are still trying to figure out some strange prodcution bugs might be causing by the "new" JDK. One of my project manager friends who works for a major bank is working on their way to new WebLogic installation taht supports JDK 1.4 this week. (05/2006)

As far as I can see, we won't be doing the next upgrade for at least another 4 to 5 years. In the mean time, Spring Framework will still be our best friends for many years to come. :-)

For those who won't be using Tomcat, the JEE5 really means not much at the present time. (I will start to refresh my skills when Tomcat is ready.) However, till now, I still don't know how much better the Java annotation can help to ease the XML configuration world. Only time will tell. (in antoher 5 years)

For those who won't be using Tomcat, the JEE5 really means not much at the present time. (I will start to refresh my skills when Tomcat is ready.)

Hmmm... What about EJB3.0 and truly Object Oriented persistence based on such ORM frameworks as Hibernate or Oracle Toplink? What about POJOs that implement business logic?
Finally "domain model" architectural pattern (M.Fowler) has a chance to gain popularity in enterprise deployments.So far "anemic entity" or "transactional script" antipatterns occur way too often.

Personaly I think EJB3.0 is a revolution :) (for Java EE of course , because Hibernate and Toplink have been available for quite a time)

http://www.enterpriseware.eu

Hmmm... What about EJB3.0 and truly Object Oriented persistence based on such ORM frameworks as Hibernate or Oracle Toplink? What about POJOs that implement business logic?Finally "domain model" architectural pattern (M.Fowler) has a chance to gain popularity in enterprise deployments.So far "anemic entity" or "transactional script" antipatterns occur way too often.Personaly I think EJB3.0 is a revolution :) (for Java EE of course , because Hibernate and Toplink have been available for quite a time)

Well, there was no technical need to wait EJB 3.0 to avoid antipatterns.
It is not the case to reopen a debate on JDO/JPA or Annotations misuse, but the facts are there.
IMO, EJB 3.0 is a last resort for an overselling technology rather than a revolution.

Guido

Hmmm... What about EJB3.0 and truly Object Oriented persistence based on such ORM frameworks as Hibernate or Oracle Toplink? What about POJOs that implement business logic?Finally "domain model" architectural pattern (M.Fowler) has a chance to gain popularity in enterprise deployments.So far "anemic entity" or "transactional script" antipatterns occur way too often.Personaly I think EJB3.0 is a revolution :) (for Java EE of course , because Hibernate and Toplink have been available for quite a time)

Well, there was no technical need to wait EJB 3.0 to avoid antipatterns.It is not the case to reopen a debate on JDO/JPA or Annotations misuse, but the facts are there.IMO, EJB 3.0 is a last resort for an overselling technology rather than a revolution.Guido

RE: EJB 3.0 is a last resort for an overselling technology rather than a revolution.

+1

Rick Hightower (linked in),blog

Personally I think EJB3.0 is a revolution :)

As you say, it may be a revolution for EJB, but it isn't for current users of POJO persistence, and I think it could have been so much better. It is based, I believe, on JDO, Hibernate and Toplink. I have no experience of Toplink, but EJB 3.0 definitely seems to be a subset of the rich features of Hibernate and JDO 2.0.

Personaly I think EJB3.0 is a revolution :) (for Java EE of course , because Hibernate and Toplink have been available for quite a time)

Is it a revolution if you're following someone else's (well worn) footsteps?

Standards shouldn't be revolutions, they should be evolutionary and look at the world around them. EJB3 did that, to an extent, so it's better than it has been...

Personaly I think EJB3.0 is a revolution :) (for Java EE of course , because Hibernate and Toplink have been available for quite a time)

Is it a revolution if you're following someone else's (well worn) footsteps? Standards shouldn't be revolutions, they should be evolutionary and look at the world around them. EJB3 did that, to an extent, so it's better than it has been...

It seems they deviated from the path quite a bit.

EJB 3.0 is much better than EJB 2.x.
If you compare EJB3 to an older version
of EJB, EJB3 is a boon; however,
if you compare EJB3 to Spring and
Hibernate, it stinks.

The related OR (Object Relation)
Persistent API does not have a criteria
API specified; any persistent API that
does not define a criteria API is not
finished.

The AOP support in EJB3 is broken.
EJB3 has a method interceptor, but
no pointcuts. In addition, the method
interceptors are declared and imported
with class-level annotations. This
effectively tightly couples the class
to the method interceptors that decorate
it (Can you smell the bad odor?).

Rod Johnson mentioned thess
same problems about EJB3 Method
Interceptors at TSS (in his
talk "Are We There Yet") and went on to
mention many limitations on the
@Resource style of DI, the absence
of FactoryBeans, post
processors, Constructor Injection,
lists/maps, and a lot of the features
Spring developers know and love are
just missing. The EJB3 JSR members
did not look enough at the prior art
in this space and created their own
limited version of what was already
available.

After three years of deliberation,
the JCPs delivered EJB3, which is
inferior to de facto standards. Many
parts of EJB3 are a big step backward
from Spring, and, to many,
EJB3 is broken. As Bruce Tate says
about EJB3: "Don't make me eat the
elephant again."

Yes, that's why I said "to an extent"... It's like Guy Steele's quote:

"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

- Guy Steele, Java spec co-author

So EJB3 will drag people halfway from EJB2 towards Spring / Hibernate / JDO. Then they'll be able to see what the value of those other de-facto standards are as they run into the limitations.

Yes, that's why I said "to an extent"... It's like Guy Steele's quote:

"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."- Guy Steele, Java spec co-author

So EJB3 will drag people halfway from EJB2 towards Spring / Hibernate / JDO. Then they'll be able to see what the value of those other de-facto standards are as they run into the limitations.

For once we are in violent agreement. :o)

It is good to be on the same side of any argument with you.

EJB3 is an gateway drug to something better...

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

The AOP support in EJB3 is broken.EJB3 has a method interceptor, but no pointcuts. In addition, the method interceptors are declared and imported with class-level annotations. This effectively tightly couples the class to the method interceptors that decorate it (Can you smell the bad odor?).

The EJB3 JSR members did not look enough at the prior art in this space and created their own limited version of what was already available.After three years of deliberation,the JCPs delivered EJB3, which is inferior to de facto standards. Many parts of EJB3 are a big step backward from Spring, and, to many,EJB3 is broken. As Bruce Tate says about EJB3: "Don't make me eat the elephant again."

Magic !!!!
Evidence made clear.

Guido.

I am honestly suprised.
I guess use tiles everyone.

.V

I've never gotten why the portlet spec decided to make their own request/response artifacts instead of going the route of compositions or event objects to represent what they needed (EditEvent has a ServletRequest/Response). Most portlet containers that I know of still have to adapt the servlet spec anyways for all other technologies in the webtier, I just don't get it.

Best News Of The Month, Congrats.

Best News Of The Month, Congrats.

Well, it is only May 3. :) Things might even get better in a few days. ;)

As I can see, Tomcat 6 will not be released soon. I am using MyFaces will migrate to JSP 2.1/JSF 1.2 for new projects as soon as possible.

It is redicules, but the only way to upgrade the Web tier platform soon is to migrate from a Web tier only server to a full Java EE 5 server.

Nebojsa

As I can see, Tomcat 6 will not be released soon. I am using MyFaces will migrate to JSP 2.1/JSF 1.2 for new projects as soon as possible.It is redicules, but the only way to upgrade the Web tier platform soon is to migrate from a Web tier only server to a full Java EE 5 server.Nebojsa

You dont have to upgrade yet, MyFaces as yet does not have implemented the JSF1.2 specs, but soon will.
I am not sure how long it will take to implement 1.2 but I am pretty confident that by the time MyFaces is on 1.2 level servlet runners having the new JSP specs implemented will exist.
(Until then you still can use the 1.1 code branch)
I do not see a real issue here, except that people have a need for some 1.2 stuff, but MyFaces does not support 1.2 currently, but soon will.

except that people have a need for some 1.2 stuff, but MyFaces does not support 1.2 currently, but soon will.

Is there any (coarse) roadmap available for MyFaces 1.2? What does 'soon' mean? Are we talking about a few months or is something like a year more in the right direction?

Although the article is 5 years old, it still is interesting to see how Java EE has evolved over the years. The changes made to it, some were lasting while some were not. All in all, Java is one of the most useful programming languages ever. I can see the constant improvements to it and it lends to its longevity.

Paul - http://www.connetu.com