Roberto Chinnici has written up the current state of the Java EE 6 profiles proposals. The Java EE 6 expert group would like to gather feedback on what the web profile should contain - because due to time constraints, they can't actually finish support for more than one profile. The basic web profile has these APIs: Servlet 3.0, JSP 2.2, JSR-45 (Debugging Support for Other Languages), EL 1.2, JSTL 1.2, and JSR-250 (Common Annotations for the Java Platform). The controversial elements for inclusion are: EJB 3.1 (Lite), JTA 1.1, JPA 2.0, JSF 2.0, and Web Beans 1.0. Roberto points out two points: Web Beans and JSF 2.0 inclusion are fairly controversial, and on EJB 3.1:

"EJB 3.1 (Lite)" refers to the idea of allowing implementations to deliver a subset of EJB 3.1. The contents of this "lite" subset are wholly undecided at this point, but as an example it might include the annotation-based programming model introduced in EJB 3.0, restricted to session beans with local interfaces (only). In other words, you could write an annotated session bean with a local interface and use it in your Web Profile-compliant product (assuming (B) is accepted, that is). But, for example, you could not write a EJB 2.1-style session bean, or an EJB 3.0 message-driven bean, or a EJB 3.0 stateful session bean with a remote interface. It's important to note that proposal (B) assumes that "EJB 3.1 (Lite)" will exist, but this is a decision that is entirely up to the EJB 3.1 expert group (JSR-318), where it's going to be prioritized against other features. The precise definition of what comprises "EJB 3.1 (Lite)" is also left to the EJB 3.1 expert group, with no particular proposal being put forward as of today.

There is a lot more here; compatibility is an issue, and reasonings behind the choices themselves are an issue. The JSF/Web Beans controversy is understandable. JSF is not extremely heavy, by any means, but it's also not very light - and considering how many people are not using JSF, a reliance on it in the basic profile seems a little arbitrary. That said, having a baseline - especially a useful baseline - is also good. What do you think of the profile? Should it go for the heavier profile that offers local EJBs, transactions, and JPA, or keep to what people normally thinks of as the "more pure" servlet technologies? If it should include the extended APIs, what about JSF? (If JSF is "heavy," why wouldn't JSP be considered "heavy" as well, since it requires a compiler to work?)

Hi, Ouf ! Finally some feedback from the Java EE 6 crew :D Personally, I've voted for the A proposition as I consider shipping JSF, JPA and EJB Lite to be a sort of "imposing" Sun Choices over user's. As you pointed it out, not everybody uses these technologies, so to be fair, we should stick to the bare minimum in the web profile, i.e. Servlet API (plus common-annotations, etc.) to provide a foundation upon wich other framworks can be build. JSP is as you said heavy and a bit cumbersome here as it is no more used by the major Web Frameworks (JSF+facelets, Wicket, Tapestry, etc.), but for the sake of the ascendant compatibility, I think that including it is a necessity. To conclude, I'll quote a friend: "The Web profile should be what it takes to make Tomcat a reference implementation". Well said ;)

Thanks for sharing Interesting post. Thanks for taking this opportunity to discuss this, I appreciate with this and I like learning about this subject. If possible, as you gain information, please update this blog with more information. I have found it really useful.  Federal resumes

I've been lurking on this JSR's list since the beginning. I never understood the point of branding something the user community *already* has and *already* can distribute a.k.a Tomcat. This is just a marketing exercise and pointless and provides zero value for the user community. IMO, the profiles that go beyond Tomcat are the interesting profiles as they could define things that the community *does not* have. -- Bill Burke JBoss, a division of Red Hat http://

"The Web profile should be what it takes to make Tomcat a reference implementation".

I've been lurking on this JSR's list since the beginning. I never understood the point of branding something the user community *already* has and *already* can distribute a.k.a Tomcat. This is just a marketing exercise and pointless and provides zero value for the user community.

IMO, the profiles that go beyond Tomcat are the interesting profiles as they could define things that the community *does not* have.

--
Bill Burke
JBoss, a division of Red Hat
http://

I also do not want to see the web profile being JUST what tomcat is - a servlet container. Tomcat is so bare bones you need to add things to complete it. Make the web profile at least usable without having to add 30 MB of jar files to my project. Put JavaMail, JPA 2.0, JTA, JSF 2.0, WebBeans, and other things commonly used in web applications. BTW JPA isn't Sun forcing an implementation on you. Sun is only one of many companies in the expert group. JPA is an API and there are many implementations such as Hibernate, TopLink, OpenJPA, etc. Also remember that JPA 2.0 in Java EE 6 will have the missing bits.

BTW JPA isn't Sun forcing an implementation on you. Sun is only one of many companies in the expert group. JPA is an API and there are many implementations such as Hibernate, TopLink, OpenJPA, etc.

Yep, I'm perfectly aware of the fact that JPA is an API and that there are many implementations, but what I wanted to point it out is that there *are people out there not using JPA API*, working instead with things like native Hibernate, iBatis, bare JDBC or Spring JDBC, torque, you name it.

Also remember that JPA 2.0 in Java EE 6 will have the missing bits.

Amen, amen ... and JSF 2.0 also. Just for info: I'm a JSF/JPA user.

Why would the "Web" Profile not include the "Web"Beans specification? Are we trying to discourage the possibility of having a standard component model in web applications? Or maybe the WebBeans specification needs to lose the Web prefix and become an extension to the runtime itself? William

Why would the "Web" Profile not include the "Web"Beans specification? Are we trying to discourage the possibility of having a standard component model in web applications? Or maybe the WebBeans specification needs to lose the Web prefix and become an extension to the runtime itself?

William

Its "Basic Web" profile, not "Web" profile. So it makes sense to be as light as possible. Profile (B) does include Seam. I can see a lot of usages for both the A (Basic web) and the B Profile. For example, some ppl still, for whatever reason, want to build spring + tomcat + hibernate apps, in such cases, a Profile A tomcat equivalent container is more than enough.

Why would the "Web" Profile not include the "Web"Beans specification? Are we trying to discourage the possibility of having a standard component model in web applications? Or maybe the WebBeans specification needs to lose the Web prefix and become an extension to the runtime itself?

William

Its "Basic Web" profile, not "Web" profile. So it makes sense to be as light as possible. Profile (B) does include Seam.

I can see a lot of usages for both the A (Basic web) and the B Profile. For example, some ppl still, for whatever reason, want to build spring + tomcat + hibernate apps, in such cases, a Profile A tomcat equivalent container is more than enough.

Two notes for the sake of clarity here: * As Roberto explained in his blog, "we cannot support a large number of profiles in the desired timeframe for the Java EE 6 platform. Here "large" really means "more than one"." So, in Java EE 6 there will be only one Web Profile. * If it really comes to the name, there's no "basic" in that. Neither in the JSR proposal (http://jcp.org/en/jsr/detail?id=316), nor in Roberto's blog entry. The use of the word "basic" in this TSS story might have been a bit misleading.

Thanks for the clarification. In this case I'd pick profile B but with either only JSP or JSF. No need for both. There's no way to satisfy everyone and there's just too many drop in web frameworks out there anyway.

Thanks on your marvelous posting! I quite enjoyed reading it, you could be a great author.I will make certain to bookmark your blog and definitely will come back from now on. I want to encourage yourself to continue your great writing, have a nice morning!

how to remove a mole at home

What are you doing, Trying to compete with Hellman mayonnaise! Hellman Real, Hellman Light, Hellman Reduced Fat. This is why Spring continues to grab market share.

What are you doing, Trying to compete with Hellman mayonnaise!
Hellman Real, Hellman Light, Hellman Reduced Fat. This is why Spring continues to grab market share.

Actually, all things considered (including SpringSource' employment of members of the EG) it's entirely possible that a Spring implementation of the Web Profile could be created.

What are you doing, Trying to compete with Hellman mayonnaise!
Hellman Real, Hellman Light, Hellman Reduced Fat. This is why Spring continues to grab market share.

Does Spring continue to gain market share ?

What are you doing, Trying to compete with Hellman mayonnaise!
Hellman Real, Hellman Light, Hellman Reduced Fat. This is why Spring continues to grab market share.

Does Spring continue to gain market share ?

It's not mathematically possible to have more than 100% is it? My vote would be to leave JSF out, and in fact delete all copies of the source code on the planet, and henceforth refer to JSF to "the view technology that must not be named" Are there any magical drag and drop tools which let you create *good looking*, again, *good looking* web applications. +1 for creating a Spring + Spring Webflow + Sitemesh + jQuery JEE profile

Good to hear that such profiles are taken into consideration!

The basic web profile has these APIs: Servlet 3.0, JSP 2.2, JSR-45 (Debugging Support for Other Languages), EL 1.2, JSTL 1.2, and JSR-250 (Common Annotations for the Java Platform).

BASIC spells like get rid of everything possible... I'd go so far as that means absolutely necessary - Servlet 3.0 - EL 1.2 - Common Annotations (JSR 250) optional: - JSP 2.2 (although already questionable) - JSTL 1.2 unnecessary: - Debugging Support for Other Languages (JSR 45) Why? Embedded services will become more and more important. One of the nicest embedded resources (in my opinion) is the Java-stamp controller. Small as a standard US-postage stamp having controller-IO and a servlet engine. Operating system is a Java (V)M. And on such a system you want to keep stuff basic. Why no JSP? As soon as you take JSF you can easily get rid of JSP (using JSFTemplating or Facelets). And without JSP no JSTL needed. Why no "debugging support for..."? Just not needed to write a simple JAVA webapplication. so much for now... "Shields up, Scotty"

Since they seem to be advocating some kind of "plug in" (or at least "drop in") architecture, why not have a stripped web profile, and then offers the other components as, well, components. If folks want to add in JSP or EJB Lite or JPA, they can "drag and drop" the jar over and have it "just work". In truth, though, much of this is moot, as we already have a lot of this. Yank JSP out of the servlet container is pretty much trivial. Jetty can be as small as you want, Spring lets you "build up" as many services as you like. JBoss is already a pretty modular app server, and GF is getting there in v3, make du jour service more practical. So, that begs the question of whether ANY of this needs to be done? Save perhaps standardizing the modular parts of the container (so you can swap out JBoss bits with GF bits, say...). I would favor "ejb lite" as a "plop in" for a servlet container, but Spring is pretty damn close, if only I could just reuse my Stateless Session Beans as is and do all this with minimal configuration, I'd be giddy.

hmmmm So we can expect another mess. Can you give this assignment to spring team.They serving JEE well. We are listening java 6,java 7.What about java 5?? i heard rumors that market refused to adopt java5 so why you are giving birth to new babies..

What about java 5??
i heard rumors that market refused to adopt java5 so why you are giving birth to new babies..

Any substantiation to that rumor? I know there are a lot of shops still trying to adopt J2EE 1.4, but at the same time, Java EE is hitting the adoption curve one can expect to see at this point in its lifecycle. After all, Java EE isn't some environment that I won't bother naming where everyone can change overnight to some new wonky architecture because the wind's shifted.

What everybody here is advocating is what they are already doing. I think that is missing the point. I think that the web profile should be useful, not something devoid of everything, just so you can add all your own favorite non-standard pieces. To me, for the web profile to be useful, it needs to have Web Beans, and by definition JPA, JSF and JTA. This will give people a lightweight, standards compliant profile that can actually be used to build sophisticated applications.

What everybody here is advocating is what they are already doing. I think that is missing the point.

I think that the web profile should be useful, not something devoid of everything, just so you can add all your own favorite non-standard pieces.

To me, for the web profile to be useful, it needs to have Web Beans, and by definition JPA, JSF and JTA. This will give people a lightweight, standards compliant profile that can actually be used to build sophisticated applications.

But JSF sucks ass in a major way. A lot of people agree with me here. I know a lot of people disagree too, and that's fair enough. If a lot of people agree that JSF sucks, what's the point of it being the 'standard'. J2EE was a standard too once, before we all acknowledged that it sucked and used Spring instead.

If you don't like Java EE, then why do you care what's included in the EE6 web profile?

Jason,

If you don't like Java EE, then why do you care what's included in the EE6 web profile?

It's not that I don't "like" Java EE. I've helped integrate Jetty into numerous EE containers as the web tier. I fully expect that Jetty will be used in some products that are Web Profile compliant containers, and as such I've got an opinion on what that profile should contain. Whilst musing on the proposition "what should a Web Profile contain" - and I still maintain it shouldn't include JSP - it suddenly struck me that I actually see more and more use of containers that offer flexible pluggability of API impls. And it occurred to me that perhaps a lot of the value that is traditionally attributed to EE, is actually derived instead from the standardization and therefore commoditization of the various APIs (jta, jdbc, jpa, etc etc). So all you need is the ability to plug the API impl mix of you choice into your web-based container and you're good to go. Just thinking out loud. regards Jan

Jan, My comment was directed at Greg, not you. I definitely agree that vendors should be able to mix and match arbitrary APIs regardless of the platform or profile specs. I think the strength of a profile comes from having well defined integration, which leads to less hassle for the end-developer( you don't have to research/find the magical combination of frameworks and versions that work well together).

If you don't like Java EE, then why do you care what's included in the EE6 web profile?

For my 2c, I don't want people in 'manager land' reading about web profiles incl. JSF and thinking they're a good thing, and then specifying that they must be used in a project. Something like Geronimo (http://www.theserverside.com/news/thread.tss?thread_id=48474) which provides the capability to implement a profile concept without deciding what's in it seems better to me. I haven't used Geronimo yet in a project (use JBoss + Tomcat), but Geronimo is starting to interest me because of its maven-like capability to store .jar files in a sensible way.

If you don't like Java EE, then why do you care what's included in the EE6 web profile?

Hi Jason, I can tolerate most parts of JEE (as different from J2EE), with the exceptions: - JSF is rubbish. It's forward-based, has no notion of a conversation, etc, etc. Give me JSP 2.0 tags + jQuery + Sitemesh any day. - JPA is dumbed down enough to be annoying. e.g. @PrePersist and @PostPersist aren't as good as a Hibernate interceptor which is friendly to being Spring injected. JPA needs a little more work, basically add all the missing Hibernate features back in. - Spring, for me, is better than the seemingly dumbed down rest of JEE. i.e. revamped EJBs. My opposition is to have yet more half-baked stuff foisted upon us, when in the end it runs the risk of being another J2EE/Emperor's New Clothes experience. I would be interested to hear a discussion of Geronimo's maven-based .jar storing feature by people who know more about it than me. A Geronimo approach, which seems to be close to providing the capability to store a profile would still allow a 'Web Profile' set of jars to be specified, but also allow people to choose their own stack.

I think the point is that it is impossible to produce any one-size-fits-all solution. The only thing you can do is to produce a reasonable minimum and then let people add the features they want in a pluggable way. I personally don't think that JSP and related libs should be mandatorily part of a Web Profile. The web has moved on rapidly and there are a plethora of both client and server side techologies out there now. To (continue to) annoint one presentation technology as the "chosen" one is a retrograde step IMHO. I've blogged about this here: http://blogs.webtide.com/janb/ regards Jan

This was a great article. I really enjoyed it. Thanks for posting it.

get rid of skin tags

There are plenty of information about this topic in the net & some are definitely better than others.

Attic Conversion