Using RESTClient with Java's HttpServlet
I previously blogged about using RESTClient with the Sun JVM-provided HTTP Server. As I stated in that blog posting, I intend to use these tools to demonstrate HTTP and REST concepts at Rocky Mountain Oracle Users Group (RMOUG) Training Days 2009. I also intend to use the tried and proven Java HttpServlet in this presentation.
When I started using the Java servlet back in 2000, I read about the HttpServlet methods that correspond to the significant HTTP methods, but I didn't really override any methods in the majority of my servlets other than doGet and doPost. Looking back on the early servlet-focused books and articles, it is not surprising that this was the case because these materials focused on those two methods as well.
Although the Javadoc-based API information for Java EE 5 briefly discusses alternative methods in
Roy Fielding's REST dissertation has been a significant catalyst in motivating many of us to think about HTTP differently. Specifically, we are now more inclined to think about the other methods supplied with HTTP. While many tools and browsers do not provide great support for all the major HTTP methods, the Java servlet has provided this support for some time and is an excellent mechanism for implementing and simulating operations that take advantage of the major HTTP methods.
It is very easy to take advantage of
SimpleHttpServer.java
This class can be referenced in the Java EE web descriptor file (
web.xml
If we build the servlet shown above and assemble it with the
For the example in this blog posting, I am deploying the assembled WAR with the servlet and
Note that in both cases, the default method used for the browser communication with the servlet was HTTP GET. I will now begin using RESTClient to easily communicate with this servlet with alternative HTTP methods. This tool is provided as an executable JAR and is easily used, but additional instructions on using it are available here and here.
Because the browsers automatically demonstrated use of a client using HTTP GET to communicate with the server, I will begin showing RESTClient examples with GET as well. The following two screen snapshots demonstrate RESTClient showing the headers and then the body of the response. The HTTP response information is shown at the bottom of the UI.
HTTP GET Response Headers
HTTP GET Response Body
The two screen snapshots above use RESTClient to show the headers and body of the HTTP GET response. For POST, PUT, and DELETE, I will only show the bodies.
HTTP POST Response Body
HTTP PUT Response Body
HTTP DELETE Response Body
The response body for the TRACE method is shown next.
HTTP TRACE Response Body
The HTTP HEAD method works like the GET, but intentionally does not include a body. Similarly, the most interesting portion of the response for OPTIONS is also in the header. Because the HEAD's body is empty and the header looks like that for GET, I don't show it here. For OPTIONS, I show the headers rather than the bodies of those responses next. Note that the options provided by the server are shown in the "Allow" header field of this response.
HTTP OPTIONS Response Headers
As the "Allow" header field in the OPTIONS response indicates, the server supports the HTTP methods GET, HEAD, POST, PUT, DELETE, TRACE, and OPTIONS.
Conclusion
Although Java servlets are more than a decade old, they remain a powerful and highly useful technology. While they may not be as trendy as younger and more currently hip technologies, this blog posting serves as a reminder of how relatively easy it is to apply their rich features to modern-day development. Servlets have supported the major HTTP methods for many years and because of the
When I started using the Java servlet back in 2000, I read about the HttpServlet methods that correspond to the significant HTTP methods, but I didn't really override any methods in the majority of my servlets other than doGet and doPost. Looking back on the early servlet-focused books and articles, it is not surprising that this was the case because these materials focused on those two methods as well.
Although the Javadoc-based API information for Java EE 5 briefly discusses alternative methods in
HttpServlet that can be overridden, many tutorials available even today focus on doGet anddoPost. For example, the highly useful Java Servlet API Tutorial has an HTTP Support section that mentions the other methods but focuses on doGet, doPost, doHead. Similarly, the Java EE 5 Tutorial(PDF) also focuses on use of the HttpServlet's doGet method.Roy Fielding's REST dissertation has been a significant catalyst in motivating many of us to think about HTTP differently. Specifically, we are now more inclined to think about the other methods supplied with HTTP. While many tools and browsers do not provide great support for all the major HTTP methods, the Java servlet has provided this support for some time and is an excellent mechanism for implementing and simulating operations that take advantage of the major HTTP methods.
It is very easy to take advantage of
HttpServlet's support for major HTTP methods. This is demonstrated in the next code sample for the Java servlet class SimpleHttpServer.java:SimpleHttpServer.java
- package dustin.flex.rest;
- import java.io.IOException;
- import java.io.PrintWriter;
- import javax.servlet.http.HttpServlet;
- import javax.servlet.http.HttpServletRequest;
- import javax.servlet.http.HttpServletResponse;
- /**
- * Simplistic Java EE server-side application intended for demonstration of
- * HTTP methods often use in REST-based applications.
- *
- * @author Dustin
- */
- public class SimpleHttpServer extends HttpServlet
- {
- /**
- * Servlet method responding to HTTP GET methods calls.
- *
- * @param request HTTP request.
- * @param response HTTP response.
- */
- @Override
- public void doGet( HttpServletRequest request,
- HttpServletResponse response ) throws IOException
- {
- final PrintWriter out = response.getWriter();
- out.write("GET method (retrieving data) was invoked!");
- }
- /**
- * Servlet method responding to HTTP POST methods calls.
- *
- * @param request HTTP request.
- * @param response HTTP response.
- */
- @Override
- public void doPost( HttpServletRequest request,
- HttpServletResponse response ) throws IOException
- {
- final PrintWriter out = response.getWriter();
- out.write("POST method (changing data) was invoked!");
- }
- /**
- * Servlet method responding to HTTP PUT methods calls.
- *
- * @param request HTTP request.
- * @param response HTTP response.
- */
- @Override
- public void doPut( HttpServletRequest request,
- HttpServletResponse response ) throws IOException
- {
- final PrintWriter out = response.getWriter();
- out.write("PUT method (inserting data) was invoked!");
- }
- /**
- * Servlet method responding to HTTP DELETE methods calls.
- *
- * @param request HTTP request.
- * @param response HTTP response.
- */
- @Override
- public void doDelete( HttpServletRequest request,
- HttpServletResponse response ) throws IOException
- {
- final PrintWriter out = response.getWriter();
- out.write("DELETE method (removing data) was invoked!");
- }
- @Override
- public String getServletInfo()
- {
- return "Server-side application demonstrating HTTP methods.";
- }
- }
This class can be referenced in the Java EE web descriptor file (
web.xml) as shown next.web.xml
- <?xml version="1.0" encoding="UTF-8"?>
- <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
- version="2.5" xmlns="http://java.sun.com/xml/ns/javaee">
- <display-name>Simple Servlet Example Demonstrating Http Method Support</display-name>
- <description>Demonstrates HttpServlet Support of HTTP Methods</description>
- <servlet>
- <servlet-name>SimpleHttpServer</servlet-name>
- <servlet-class>dustin.flex.rest.SimpleHttpServer</servlet-class>
- </servlet>
- <servlet-mapping>
- <servlet-name>SimpleHttpServer</servlet-name>
- <url-pattern>/httpServer</url-pattern>
- </servlet-mapping>
- </web-app>
If we build the servlet shown above and assemble it with the
web.xml file shown above into a WAR file that is deployed to a Java EE web server, we can then have clients contact the simple servlet via one of the four HTTP methods GET, POST, PUT, and DELETE (assuming the client is capable of using these different HTTP methods). In fact, we'll also see later in this blog post that even the HTTP methods TRACE, OPTIONS, and HEAD are supported by the HttpServlet. I did not override them in my servlet above because the default implementations of these methods (doTrace, doOptions, anddoHead) typically work well for what we need.For the example in this blog posting, I am deploying the assembled WAR with the servlet and
web.xmlfile shown above to GlassFish (though any Java EE web/application server will work) using a context ofrestful. Coupled with the path defined in the web descriptor file and using the default port onGlassFish, my overall URL for accessing my servlet is http://localhost:8080/restful/httpServer. When I place this URL in my web browser, the results appear as shown in the figures below for Firefoxand for Google Chrome.
Note that in both cases, the default method used for the browser communication with the servlet was HTTP GET. I will now begin using RESTClient to easily communicate with this servlet with alternative HTTP methods. This tool is provided as an executable JAR and is easily used, but additional instructions on using it are available here and here.
Because the browsers automatically demonstrated use of a client using HTTP GET to communicate with the server, I will begin showing RESTClient examples with GET as well. The following two screen snapshots demonstrate RESTClient showing the headers and then the body of the response. The HTTP response information is shown at the bottom of the UI.
HTTP GET Response Headers
HTTP GET Response Body
The two screen snapshots above use RESTClient to show the headers and body of the HTTP GET response. For POST, PUT, and DELETE, I will only show the bodies.
HTTP POST Response Body
HTTP PUT Response Body
HTTP DELETE Response Body
The response body for the TRACE method is shown next.
HTTP TRACE Response Body
The HTTP HEAD method works like the GET, but intentionally does not include a body. Similarly, the most interesting portion of the response for OPTIONS is also in the header. Because the HEAD's body is empty and the header looks like that for GET, I don't show it here. For OPTIONS, I show the headers rather than the bodies of those responses next. Note that the options provided by the server are shown in the "Allow" header field of this response.
HTTP OPTIONS Response Headers
As the "Allow" header field in the OPTIONS response indicates, the server supports the HTTP methods GET, HEAD, POST, PUT, DELETE, TRACE, and OPTIONS.
Conclusion
Although Java servlets are more than a decade old, they remain a powerful and highly useful technology. While they may not be as trendy as younger and more currently hip technologies, this blog posting serves as a reminder of how relatively easy it is to apply their rich features to modern-day development. Servlets have supported the major HTTP methods for many years and because of the
HttpServlet's close association with HTTP, it is not surprising that the HttpServlet was ready for action when REST became a widely popular topic.Java EE and Flex: A Compelling Combination
My article Java EE and Flex: A Compelling Combination, Part 1 was published on JavaWorld today. I have presented on Java EE+Flex at Collaborate08 and at the Colorado Software Summit, but it was nice to be able to use an article to provide a little different focus on the compelling combination thatJava EE and Flex make.
In the article, I introduce Flex features, concepts, and syntax while building a Flex application that gets its data from a Java EE server. The article articulates several general advantages of Flex in addition to advantages of Flex that are specific to Java developers.
The very simple Flex-based example built up in this article provides opportunities to look at several Flex features including some ActionScript 3.0 syntax, custom component creation, styling with CSS, and use of several built-in Flex components.
The article focuses on moving the example from a completely static application with highly redundant code to a leaner application supporting dynamic data population from a Java-based server and dynamic user interaction. The mechanism used in this article for communicating with the Java back-end is Flex's built-in HTTPService. I intentionally used the non-proxied HTTPService provided with the Flex SDK rather than BlazeDS's proxied HTTPService in this first part. In the second part, I will be introducing BlazeDS to the sample application.
I did not cover GraniteDS in this first part and will not be covering it in any detail in the second part. However, for a nice introduction to Flex+Java with GraniteDS, see Franck Wolff's Migrating Java EE Web Applications to Adobe Flex and Granite Data Services.
In the article, I introduce Flex features, concepts, and syntax while building a Flex application that gets its data from a Java EE server. The article articulates several general advantages of Flex in addition to advantages of Flex that are specific to Java developers.
The very simple Flex-based example built up in this article provides opportunities to look at several Flex features including some ActionScript 3.0 syntax, custom component creation, styling with CSS, and use of several built-in Flex components.
The article focuses on moving the example from a completely static application with highly redundant code to a leaner application supporting dynamic data population from a Java-based server and dynamic user interaction. The mechanism used in this article for communicating with the Java back-end is Flex's built-in HTTPService. I intentionally used the non-proxied HTTPService provided with the Flex SDK rather than BlazeDS's proxied HTTPService in this first part. In the second part, I will be introducing BlazeDS to the sample application.
I did not cover GraniteDS in this first part and will not be covering it in any detail in the second part. However, for a nice introduction to Flex+Java with GraniteDS, see Franck Wolff's Migrating Java EE Web Applications to Adobe Flex and Granite Data Services.
Five Things to Like About Spring ... Even if You Don't Use It Directly
A while back (May 2005), Bruce Tate's article Five Things I Love About Spring was published. As one would expect, this article focused on things that the Spring Framework does for developers using Spring. There are numerous other articles on the subject and perhaps no better source on the architectural justification for and advantages of using Spring exists than the "book that started it all" (J2EE Design and Development).
In this blog entry, I briefly look at five things that the Spring framework has done or can do for Java developers who don't directly use the Spring Framework in their applications.
1. Spring prompted J2EE to become much more usable as Java EE 5.
While many Java EE developers use Spring in one way or another, some still develop with Java EE without Spring. These users still benefit from Spring because Spring's presence has helped motivate change to Java EE, particularly in terms of increased usability.
2. Spring inspired many of the Java EE 5 advancements such as dependency injection andPOJO-based development.
Not only did Spring motivate improvements to Java EE, but Spring also provided examples of techniques and approaches that enterprise developers like that Java EE could emulate. Some of these approaches were even around before Spring, but Spring popularized them as the framework itself rapidly rose in popularity.
3. Spring with Dependencies makes many useful libraries and frameworks available in a single download.
More than once, I have benefited from having a necessary open source product or library readily available from the Spring dependencies directory. This may seem like a minor thing, but it saves me a little time and potentially a lot of aggravation from having to find the appropriate web site to download the appropriate files and then unload the files. This effort is not a big deal in most cases, but there are times when I just want to try something out that I have read very quickly and the time saved from having to download it is greater than the time I spend trying it out. Spring's bundling of these dependencies can be a little reassuring regarding compatibilities and versions of the dependencies.
4. Spring developers help identify useful open source libraries and frameworks.
Related to the point above, I have learned about interesting of promising libraries and open source products simply by browsing the list of Spring dependencies. The Spring developers seem to pick the best of the compatible open source software and so, in many respects, have done research into these products that I can now take advantage of.
5. Spring provides developers with examples of design and Java coding best practices.
The Spring Framework probably shows more flexibility and extensibility than many of us need because of its nature as a common framework. That being said, we all still want a certain degree of flexibility and extensibility in our applications and Spring provides many good examples of how to achieve this. Note that I am not talking about Spring best practices here, but am rather talking about Java best practicesthat the Spring framework enables, encourages, and/or provides examples for. Because Spring is open source, we can view and get ideas from its code base.
In this blog entry, I briefly look at five things that the Spring framework has done or can do for Java developers who don't directly use the Spring Framework in their applications.
1. Spring prompted J2EE to become much more usable as Java EE 5.
While many Java EE developers use Spring in one way or another, some still develop with Java EE without Spring. These users still benefit from Spring because Spring's presence has helped motivate change to Java EE, particularly in terms of increased usability.
2. Spring inspired many of the Java EE 5 advancements such as dependency injection andPOJO-based development.
Not only did Spring motivate improvements to Java EE, but Spring also provided examples of techniques and approaches that enterprise developers like that Java EE could emulate. Some of these approaches were even around before Spring, but Spring popularized them as the framework itself rapidly rose in popularity.
3. Spring with Dependencies makes many useful libraries and frameworks available in a single download.
More than once, I have benefited from having a necessary open source product or library readily available from the Spring dependencies directory. This may seem like a minor thing, but it saves me a little time and potentially a lot of aggravation from having to find the appropriate web site to download the appropriate files and then unload the files. This effort is not a big deal in most cases, but there are times when I just want to try something out that I have read very quickly and the time saved from having to download it is greater than the time I spend trying it out. Spring's bundling of these dependencies can be a little reassuring regarding compatibilities and versions of the dependencies.
4. Spring developers help identify useful open source libraries and frameworks.
Related to the point above, I have learned about interesting of promising libraries and open source products simply by browsing the list of Spring dependencies. The Spring developers seem to pick the best of the compatible open source software and so, in many respects, have done research into these products that I can now take advantage of.
5. Spring provides developers with examples of design and Java coding best practices.
The Spring Framework probably shows more flexibility and extensibility than many of us need because of its nature as a common framework. That being said, we all still want a certain degree of flexibility and extensibility in our applications and Spring provides many good examples of how to achieve this. Note that I am not talking about Spring best practices here, but am rather talking about Java best practicesthat the Spring framework enables, encourages, and/or provides examples for. Because Spring is open source, we can view and get ideas from its code base.
BlazeDS: More Free Flex to Java EE Integration Options
Up until now, I have primarily used Flex's HTTPService and WebService to communicate between my Flex clients and the Java EE server-side business logic. With Adobe's recent announcement of the new free (as in "free beer") BlazeDS, there are more and highly productive techniques available at no charge for communicating between a Flex client and the Java EE server. Adobe has also announced plans to move portions of BlazeDS to open source (as in "free speech"). In other words, some highly useful Java EE to Flex communication mechanisms that used to have a license cost and were not open source (Flex Data Services or Adobe LiveCycle Data Services ES) will now be, at least in part, both freely available and open source.
The Adobe announcement and BlazeDS web page, along with seemingly countless blogs, talk about the basics of BlazeDS. Therefore, instead of rehashing the features of BlazeDS in detail, I'll focus in this blog entry on listing some useful resources for additional information on BlazeDS.
As part of this announcement, Adobe also announced release of the Action Message Format (AMF) specification. Besides greater development ease, other advantages of the new approaches available to developers for Java EE-to-Flex communication include potentially significantly greater performance with binary formats compared to the text/XML approaches used inherently with HTTPService and WebService. That being said, there are advantages to the HTTPService and WebService such as extremely loose coupling and high degree of standards orientation.
Adobe is releasing BlazeDS under the LPGL (version 3). There is a beta version available now and the open source version is anticipated to be available in early 2008. I was curious about Adobe's reasoning for employing the GNU Lesser General Public License (LGPL) for BlazeDS when they have already announced Flex's open source release under the Mozilla Public License (MPL), but theBlazeDS FAQ addresses this question and states that BlazeDS may be used outside of Flex and thus had different open source licensing needs than those of Flex. I find this only slightly concerning because the FAQ recommends (more than once) that lawyers (or "legal experts") be consulted if distributing BlazeDS. However, the benefits of using open source BlazeDS may be worth it to some organizations to justify the legal review and advice. Besides, it is probably best to conduct such reviews anyway with all licenses. That being said, I have really come to appreciate licenses like the Apache Foundation's Apache License Version 2 software license. They just seem easier to understand and adhere to.
Speaking of the LGPL, there are some interesting sites with more information on this. The Free Software Foundation provides an overview of licenses and, related to the GNU project, includes an article Why You Shouldn't Use the Lesser GPL for Your Next Library. Note that this last article is oriented to software library developers rather than software library users. My understanding is that the LGPL has significantly weaker copyleft protections than the ordinary GPL and that organizations are typically allowed to include LGPL-licensed libraries in proprietary products. However, I'm not an attorney and all these licenses muddy the situation and make things confusing. Popular libraries using the LGPL license include JFreeChart, JBoss Application Server (and most of its related projects), andHibernate. This doesn't seem like too bad of company for BlazeDS. JBoss's justification for LGPL is interesting reading as well.
The BlazeDS FAQ addresses what constitutes remoting and web messaging. Remoting allows Flex developers to treat server-side Java objects as if they were local to Flex objects. Because it uses the binary AMF format, it will often be significantly faster than using text/XML. As the Web in Web Messaging implies, this form of communication occurs over HTTP. The thing that appeals most to me about Web Remoting is that Java Message Service (JMS) can be used as part of this.
It is important to note that BlazeDS does not have all the features of the LifeCycle product.
Here are some useful resources for additional details on BlazeDS:
This blog entry is meant to be a single location that links to my blog entries regarding working with Flex and Java (particularly Enterprise Java). As such, this entry will be updated each time I add a new blog entry on working with Java and Flex.
The Adobe announcement and BlazeDS web page, along with seemingly countless blogs, talk about the basics of BlazeDS. Therefore, instead of rehashing the features of BlazeDS in detail, I'll focus in this blog entry on listing some useful resources for additional information on BlazeDS.
As part of this announcement, Adobe also announced release of the Action Message Format (AMF) specification. Besides greater development ease, other advantages of the new approaches available to developers for Java EE-to-Flex communication include potentially significantly greater performance with binary formats compared to the text/XML approaches used inherently with HTTPService and WebService. That being said, there are advantages to the HTTPService and WebService such as extremely loose coupling and high degree of standards orientation.
Adobe is releasing BlazeDS under the LPGL (version 3). There is a beta version available now and the open source version is anticipated to be available in early 2008. I was curious about Adobe's reasoning for employing the GNU Lesser General Public License (LGPL) for BlazeDS when they have already announced Flex's open source release under the Mozilla Public License (MPL), but theBlazeDS FAQ addresses this question and states that BlazeDS may be used outside of Flex and thus had different open source licensing needs than those of Flex. I find this only slightly concerning because the FAQ recommends (more than once) that lawyers (or "legal experts") be consulted if distributing BlazeDS. However, the benefits of using open source BlazeDS may be worth it to some organizations to justify the legal review and advice. Besides, it is probably best to conduct such reviews anyway with all licenses. That being said, I have really come to appreciate licenses like the Apache Foundation's Apache License Version 2 software license. They just seem easier to understand and adhere to.
Speaking of the LGPL, there are some interesting sites with more information on this. The Free Software Foundation provides an overview of licenses and, related to the GNU project, includes an article Why You Shouldn't Use the Lesser GPL for Your Next Library. Note that this last article is oriented to software library developers rather than software library users. My understanding is that the LGPL has significantly weaker copyleft protections than the ordinary GPL and that organizations are typically allowed to include LGPL-licensed libraries in proprietary products. However, I'm not an attorney and all these licenses muddy the situation and make things confusing. Popular libraries using the LGPL license include JFreeChart, JBoss Application Server (and most of its related projects), andHibernate. This doesn't seem like too bad of company for BlazeDS. JBoss's justification for LGPL is interesting reading as well.
The BlazeDS FAQ addresses what constitutes remoting and web messaging. Remoting allows Flex developers to treat server-side Java objects as if they were local to Flex objects. Because it uses the binary AMF format, it will often be significantly faster than using text/XML. As the Web in Web Messaging implies, this form of communication occurs over HTTP. The thing that appeals most to me about Web Remoting is that Java Message Service (JMS) can be used as part of this.
It is important to note that BlazeDS does not have all the features of the LifeCycle product.
Here are some useful resources for additional details on BlazeDS:
- Breaking News for the Flex Community (nice overview of what is and isn't in BlazeDS)
- Adobe Announces Open Source Technologies for Enterprise RIAs: BlazeDS Enables Developers to Productively Build Real-Time Data-Driven Applications
- Adobe Labs BlazeDS Page
- Action Message Format (AMF) 3
- BlazeDS External Frequently Asked Questions (FAQ)
- Adobe Open Sources Remoting and Messaging Technologies Along with AMF Protocol Specification
- James Ward's BlazeBench: Why You Want AMF and BlazeDS
- Interesting performance-related comparisons via James Ward's BlazeBenchapplication.
- Google Search on "BlazeDS"
Useful Flex/Java Integration Resources
It feels very natural to me to develop applications with Flex for the client-side and have these rich Flash-executed clients run against a back-end developed in Java EE. This blog entry contains useful links and references to resources and articles regarding use of Java with Flex and includes what I like about each resource. This blog entry may be updated occasionally as I come across useful Java/Flex resources. I do not intend to update the date on this entry so that it remains at this link.
Hybridizing Java (30 January 2007)
This Bruce Eckel weblog entry was a wake-up call for many Java developers (myself included) who had previously considered Flash/Flex as not much more than a gimmick platform/language rather than as a real programming platform/language.
Comparing the Syntax of Java 5 and ActionScript 3 (12 November 2006)
This article features a table comparing language syntax of the Java programming language and the ActionScript 3 (used in Flex) language.
Adobe Flex Development Center: Flex and Java
Numerous articles and resources on using Flex and Java, including some of those listed in this entry.
Thirty Minute Flex Test-Drive for Java Developers (20 November 2006)
This example demonstrates using Flex with many Java-oriented favorites including Spring Framework,Hibernate, and Tomcat.
Rich Internet Applications with Adobe Flex 2 and Java (10 May 2006)
Integrating Macromedia Flex with Java (1 December 2004)
This article is an early article covering (then Macromedia) Flex and Java
Data Services Made Easy for Adobe Flex Applications (11 September 2007)
This article outlines a framework for working with two freely available and commonly used means of communication between a Flex front-end and a Java back-end: HTTPService and WebService.
Hybridizing Java (30 January 2007)
This Bruce Eckel weblog entry was a wake-up call for many Java developers (myself included) who had previously considered Flash/Flex as not much more than a gimmick platform/language rather than as a real programming platform/language.
Comparing the Syntax of Java 5 and ActionScript 3 (12 November 2006)
This article features a table comparing language syntax of the Java programming language and the ActionScript 3 (used in Flex) language.
Adobe Flex Development Center: Flex and Java
Numerous articles and resources on using Flex and Java, including some of those listed in this entry.
Thirty Minute Flex Test-Drive for Java Developers (20 November 2006)
This example demonstrates using Flex with many Java-oriented favorites including Spring Framework,Hibernate, and Tomcat.
Rich Internet Applications with Adobe Flex 2 and Java (10 May 2006)
Integrating Macromedia Flex with Java (1 December 2004)
This article is an early article covering (then Macromedia) Flex and Java
Data Services Made Easy for Adobe Flex Applications (11 September 2007)
This article outlines a framework for working with two freely available and commonly used means of communication between a Flex front-end and a Java back-end: HTTPService and WebService.
Bridging Flex and Java EE
| Bridging the Java/Flex Gap | |
|---|---|
| Nuances of ActionScript Constructors (contrasted with Java constructors) | 5 December 2007 |
| More on ActionScript 3 Equality Comparisons | 24 November 2007 |
| String Comparisons in ActionScript | 23 November 2007 |
| Overriding Parent get/set Methods and Accessors | 16 November 2007 |
| ActionScript 3.0 get/set Accessors: A Peek at Java 7 Properties? | 15 November 2007 |
| Java and ActionScript: switch-case and Switching on Strings | 8 November 2007 |
| Other Resources on Using Flex and Java Together | 29 October 2007 |
This blog entry is meant to be a single location that links to my blog entries regarding working with Flex and Java (particularly Enterprise Java). As such, this entry will be updated each time I add a new blog entry on working with Java and Flex.
OpenLaszlo with Java Servlets 2.5 and Resource Injection
OpenLaszlo provides a compelling solution for building highly flexible, rich, and robust web clients that are supported on the back end by business logic and data tier implemented with Java EE (servlets and EJB3/JPA for example). OpenLaszlo supports HTTP access of the back-end servlets and the OpenLaszlo servlet download makes it very simple to incorporate OpenLaszlo with Java servlets and JSPs.
Java EE 5 uses Java annotations introduced by Java SE 5 to make development and configuration of Java EE 5 software easier for the developer. One such use of these annotations in Java EE is to use the @EJB injection in a servlet to access an Enterprise JavaBean (EJB). However, to use the @EJB annotation in a servlet, the servlet must be executed in a Java Servlet 2.5 environment.
Section 5.1 of the System Administrator's Guide to Deploying OpenLaszlo Applications covers how to implement "OpenLaszlo-enabled web applications" and Section 5.2 covers how to create a minimal OpenLaszlo server. In either case, it is likely that a developer would start with the web.xml provided with the OpenLaszlo distribution. There is no issue with this unless the developer wants to use Servlet 2.5 support for annotations.
To run Java 2.5 servlets with annotations (such as the @EJB) in conjunction with OpenLaszlo, the web.xml file that comes as part of the OpenLaszlo servlet distribution (as of 4.0.6) should be changed from being a Servlet 2.2 web.xml file to a Servlet 2.5 web.xml file. The web.xml file that is delivered with the OpenLaszlo distribution (as of 4.0.6) begins as shown (Servlet 2.2 web.xml format):
For a Servet 2.5-compatible web application, the Servlet 2.5 web.xml file should be changed to start as follows:
Note that the web.xml file for Servlet 2.2 is defined by a DTD while the web.xml file for Servlet 2.5 is defined by XML Schema. Also note that there should be no carriage return between the http://java.sun.com/xml/ns/javaee and the http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd in the Servlet 2.5 web.xml, but I used one above to allow it to fit better on the page.
Changing the web.xml file that is delivered with OpenLaszlo as part of its servlet distribution from 2.2 to 2.5 allows servlets accessed from within the same WAR file to make use of annotations and the injections that come with annotations. An alternative approach would be to bundle EJB-accessing servlets or servlets needing annotations in a separate WAR from the WAR assembled from OpenLaszlo-delivered components.
Java EE 5 uses Java annotations introduced by Java SE 5 to make development and configuration of Java EE 5 software easier for the developer. One such use of these annotations in Java EE is to use the @EJB injection in a servlet to access an Enterprise JavaBean (EJB). However, to use the @EJB annotation in a servlet, the servlet must be executed in a Java Servlet 2.5 environment.
Section 5.1 of the System Administrator's Guide to Deploying OpenLaszlo Applications covers how to implement "OpenLaszlo-enabled web applications" and Section 5.2 covers how to create a minimal OpenLaszlo server. In either case, it is likely that a developer would start with the web.xml provided with the OpenLaszlo distribution. There is no issue with this unless the developer wants to use Servlet 2.5 support for annotations.
To run Java 2.5 servlets with annotations (such as the @EJB) in conjunction with OpenLaszlo, the web.xml file that comes as part of the OpenLaszlo servlet distribution (as of 4.0.6) should be changed from being a Servlet 2.2 web.xml file to a Servlet 2.5 web.xml file. The web.xml file that is delivered with the OpenLaszlo distribution (as of 4.0.6) begins as shown (Servlet 2.2 web.xml format):
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
For a Servet 2.5-compatible web application, the Servlet 2.5 web.xml file should be changed to start as follows:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee">
Note that the web.xml file for Servlet 2.2 is defined by a DTD while the web.xml file for Servlet 2.5 is defined by XML Schema. Also note that there should be no carriage return between the http://java.sun.com/xml/ns/javaee and the http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd in the Servlet 2.5 web.xml, but I used one above to allow it to fit better on the page.
Changing the web.xml file that is delivered with OpenLaszlo as part of its servlet distribution from 2.2 to 2.5 allows servlets accessed from within the same WAR file to make use of annotations and the injections that come with annotations. An alternative approach would be to bundle EJB-accessing servlets or servlets needing annotations in a separate WAR from the WAR assembled from OpenLaszlo-delivered components.
No comments:
Post a Comment