|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 24
Messages: 24
Messages: 24
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Roberto Chinnici: Profiles in the Java EE 6 Platform
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?)
|
|
|
Message #247920
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tomcat should be the RI ;)
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 ;)
|
|
|
Message #247922
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rubberstamping Tomcat
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://
|
|
|
Message #247923
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Roberto Chinnici: Profiles in the Java EE 6 Platform
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.
|
|
|
Message #247927
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Roberto Chinnici: Profiles in the Java EE 6 Platform
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.
|
|
|
Message #247929
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
?
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 ?
|
|
|
Message #247932
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rubberstamping Tomcat
"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.
|
|
|
Message #247961
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
basic web 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"
|
|
|
Message #247963
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rubberstamping Tomcat
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
|
|
|
Message #247965
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rubberstamping Tomcat
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.
|
|
|
Message #247968
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Roberto Chinnici: Profiles in the Java EE 6 Platform
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..
|
|
|
Message #247985
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: basic web profile
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.
|
|
|
Message #247987
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Roberto Chinnici: Profiles in the Java EE 6 Platform
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.
|
|
|
Message #248006
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ?
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
|
|
|
Message #248017
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why would it?
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.
|
|
|
Message #248045
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clarification
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.
|
|
|
Message #248108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web Profile
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.
|
|
|
Message #248179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Missing the point.
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.
|
|
|
Message #248192
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Missing the point.
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.
|
|
|
Message #248195
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Missing the point.
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
|
|
|
Message #248230
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why do you care then?
If you don't like Java EE, then why do you care what's included in the EE6 web profile?
|
|
|
Message #248268
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why do you care then?
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
|
|
|
Message #248292
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why do you care then?
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.
|
|
|
Message #248321
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why do you care then?
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).
|
|
|
Message #248414
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why do you care then?
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
