I'm stepping into the world of Servlets and 3.0 in particular and I saw certain methods and annotations used in examples and tutorials which talked about this being available when JAVA 6.0 is released (which it has) and now when I try to use the above annotation for example in Eclipse it does not recognize it although I have java 1.6.013 installed and in Eclipse it says I'm using jre6.
When I tried googling it a bit I stumbled on this page regarding WebServlet Annotation where it states on the top right side: DRAFT.
what does that mean?
Is #WebServlet supported in 1.6.013 or not? is the problem with my Eclipse?
Thanks a lot for anyone who can lend me a helping hand
EDIT: I now understand I've made a bit of a mess but there is a Jar I've downloaded of the Servlets 3.0 API which at least for the #WebServlet annotation works but gives me hell.
Servlets are defined by a JSR - the Servlet Specification in JSR-154. Annotations for servlets were introduced in version 2.5 of the servlet specification. All containers that implement the 2.5 version of the specification will support annotations; your problem might lie with the container not implementing it. You can refer section SRV.14.5. Annotations and Resource Injection of the servlet spec where it is defined in black and white.
By the way, you are looking at the javadocs of Java EE 6 (which is in draft at the moment). Servlet Spec 2.5 is part of Java EE 5.
PS: The #WebServlet annotation that you are referring to, makes its appearance in Servlet Spec 3.0, which is in draft, and is a part of Java EE 6. At the time of writing this, no container is available for download that supports Servlet Spec 3.0; not even a RI (reference implementation) is available. You will find experimental builds though, but be forewarned, the spec itself is not final, so experimental builds are bound to interpet and implement the spec differently.
PPS: Glassfish v3 Preclude Preview seems to have support for most of the Java EE 6 standards. A comparison sheet provides info on what is available in Glassfish v2, v3 Preclude and v3 Preview.
At this time, GlassFish v3 provides the most complete implementation of EJB 3.1 and Servlet 3.0 along with other Java EE 6 specifications.
Following up on Vineet, simply put, 3.0 isn't in use right now, so you should focus on Java EE 5 and 2.5.
Related
I have developed a HTTP servlet that implements MessageListener and connects to a JMS-based MQ system using javax.jms.ConnectionFactoy.
The connection factory is injected to the servlet via a Resource annotation.
#Resource(name = "jms/ConnectionFactory")
private ConnectionFactory connectionFactory;
The resource is defined in the context.xml configuration file.
What I have experienced is that when I compile the servlet using Java 11, the javax.annotation.Ressource is simply ignored, while I can still lookup the resource based on its name in the context directly.
But, when I compile it using Java 8, the resource is injected to the annotated field in the servlet.
Can someone explain this?
Another point is that the javax namespace is replaced by the jakarate one, when migrating from Java EE to Jakarta EE. Most of the JMS library are still implemented using the javax.jms.* interfaces, like ConnectionFactory, Queue, etc.
Does anyone has experience how compatibility looks like or is a reimplementation of JMS libs necessary?
tl;dr
For Java 11 deployment, use Tomcat 10.1.x, Jakarta EE package naming, Servlet 6 API, and Jakarta Messaging 3.1 API.
Earlier versions may run on Java 11 too, but these versions are built specifically for Java 11 as a minimum requirement.
This combination will likely work on Java 17 as well as Java 11. Java 17 is the latest Long-Term Support (LTS) version. While support is not officially required in Jakarta EE, the various teams seem to be aiming for their latest versions to run well on Java 17.
Use Tomcat Version 10.1 for Java 11
According to Apache Tomcat Versions, Version 10.1 of Tomcat supports Java 11 while versions 9 and 10.0 are aimed at Java 8.
Package name
You will need to change your import statements from javax.*package to jakarta.*. This change in package naming is due to the transition from Oracle to the Eclipse Foundation as the stewards of Jakarta EE technology (formerly Java EE).
Servlet API
Switch to the appropriate version of the Servlet API, version 6. See Servlet specifications page.
Messaging API
Note that JMS has become Jakarta Messaging. You’ll need to adjust your import statements and version number accordingly. See specifications page.
Likewise, update your Jakarta Messaging implementation.
I understand that Struts 1 is EOL but I would like to know if a project that uses Struts 1 can work with Java EE7 or do I have to stop using Struts or start using Struts 2
I don't seem to find any documentation of that matter.
Struts only uses Servlet API from the EE implementation. As far as I know it's designed to be backward compatible with other servlet specifications. But you can try it on your own risk, because it might not be built or tested under the new specs. The best approach is to build the framework yourself to see if you have any problems with it. On the docs site (which included with the distro and no longer available online) and on Maven site you can find which Servlet API was supported, this information is also in release notes.
You can use old Struts as I already said on your own risk, means this framework is no longer supported. If you need a support from the community then you should upgrade to Struts 2.
I was just wondering where exactly i could get the javadocs for jboss libraries?
Whenever i mouse over some element from a certain framework(eg. servlets) pops up with
Note: This element neither has attached source nor attached Javadoc and hence no Javadoc could be found.
I am currently using Eclipse.
You need javadoc for the Java EE specifications as JBoss is an implementation of it.
So get the javadocs for Java EE specification that your JBoss is implementing.
You can download the javadoc for Java EE 6 from here :
Java EE 6 Update 2 Javadocs
You should actually be looking into getting the generic JavaEE API documentation into your Eclipse, and not the one specific to JBoss. After all (in a perfect world) your code should only depend on generic JavaEE features, not the JBoss implementation.
As for how to get JavaEE Javadoc, these two questions should explain it all:
Enabling full documentation for Java EE in eclipse
Integrating Javadoc for Java EE 6 API into Eclipse
CDI and Bean Validation are Java EE 6 Standard Specifications. Nevertheless, I can use both within Java EE 5 Application Servers (and also within Java SE) by just adding the libraries to the project.
Is this correct?
Are there any disadvantages of using both in Java EE 5 application servers instead of Java EE 6 application servers?
I have to use the Oracle 11 g Suite and JDeveloper. In the meantime, JDeveloper supports JSF 2.0, but I cannot find any support for Bean Validation or CDI. Nevertheless, this is not a problem. There is no IDE support (for code-generation, a step-by-step-guide, or whatever), but I can use these libraries by using the simple java editor. Right?
Java EE 6 is basically a collection of APIs. An application server is Java EE 6 compliant if it implements all those specifications. But you can still use the APIs in an Java EE 5 compliant application server. Some people even put EJBs into Tomcat, so technically that's possible. Still it makes sense to use a compliant AS, as it also provides all the services related to the specs.
I believe that's correct.
The disadvantage is that you're a version behind. You may have to modify your code if and when you decide to upgrade to Java EE 6 (e.g. new imports, etc.)
You can pretty easily add Apache OpenWebBeans or JBoss Weld (choose one of the 2 CDI implementations) to your WEB-INF/lib and register the servlet listeners in your web.xml manually. Voila, then you have CDI support!
For JSR-303 Bean Validation it's a bit more tricky, because only JPA2 and JSF2 makes use of it. So you would need to add Myfaces2 and Hibernate-3.5, EclipseLink2 or OpenJPA2 to your local jars and disable the container provided variants.
Before I delve into JSF 2.0 I want to clarify my understanding of JSF 2.0 by finding answers to the following:
What are the differences between the reference implementation and MyFaces?
Can jsf 2.0 with either reference implementation or MyFaces be deployed on any servlet
container, i.e. tomcat/jetty, or must it be deployed only on a Java EE compliant container?
How difficult is it to create custom tags? For example a pagination link tag, similar to what is available in Grails?
Is it possible to use *Faces (i.e. PrimeFaces, RichFaces, etc) with a javascript library like jquery or yui? Are any conflicts created by doing so?
1: What are the differences between the reference implementation and MyFaces?
They are developed by different teams. Since both are supposed to adhere the JSF 2.0 spec, there ought to be no differences with regard to the base functionality as specified in JSF 2.0 spec. However, with regard to exposed and fixed bugs, there may be differences. My personal preference is Mojarra (the reference implementation).
2: Can jsf 2.0 with either reference implementation or MyFaces be deployed on any servlet container, i.e. tomcat/jetty, or must it be deployed only on a Java EE compliant container?
Yes. JSF 2.0 only requires a minimum of Servlet 2.5 API. So any Servlet 2.5 compatible container or even Java EE 5 applicationserver suffices. You may only need to disable the builtin JSF 1.2 API in a Java EE 5 applicationserver whenever you want to use JSF 2.0. Or, better, just use a Java EE 6 application server (Glassfish 3, JBoss AS 6, etc) since it already ships with JSF 2.0.
3: How difficult is it to create custom tags? For example a pagination link tag, similar to what is available in Grails?
When using Facelets as view technology (by default used in JSF 2.0), this should be relatively simple with a template or a composite component. Since it's basically just XML, no Java code is necessary.
4: Is it possible to use *Faces (i.e. PrimeFaces, RichFaces, etc) with a javascript library like jquery or yui? Are any conflicts created by doing so?
Even more, both PrimeFaces and RichFaces ships with jQuery (UI) builtin and PrimeFaces also YUI. That's also where they get their fancy look'n'feel and/or special effects from. As to conflicts with own jQuery scripts, just use jQuery.noConflict() to suppress it.
When you're ready to dive in JSF 2.0, I can recommend the following tutorials:
My JSF 2.0 tutorial with Eclipse and Glassfish
Mkyong.com JSF 2.0 tutorials/references
Coreservlets.com JSF 2.0 tutorial
Update as per the comment:
However, could you elaborate on why your personal preference is Mojarra (the reference implementation)?
Because I am an avid user of Mojarra. True, it's subjective :)
Objectively said, MyFaces was the better choice during JSF RI 1.1 times. Less bugs and better performance. However, since the new JSF RI dev team during the JSF RI 1.2 times, a lot was improved/fixed. As of now there are no technical reasons to prefer the one over the other. It's at highest the degree of exposed and fixed bugs (maintenance/support).
Related questions:
MyFaces 1.2 causes Tomcat 6 to crash
Memory leaks in MyFaces 2.0
Intermittent ViewExpiredException in MyFaces 2.0
Mojarra or MyFaces?
Disadvantages of JSF 2.0 (a bit of history)