Java EE 7新特性深度解析：从Servlet到Web服务

Java.EE.7

需积分: 10 152 浏览量更新于2024-07-22 收藏 4.85MB PDF 举报

"《Apress.Introducing.Java.EE.7.Jul.2013》是一本介绍Java EE 7新特性的指南，该书详细阐述了Java EE平台各项技术的更新内容，包括Java Web Tier、业务逻辑与数据处理、Web服务与HTML以及平台内部机制等内容。全书共计216页，特别关注了Servlet技术的升级，旨在帮助开发者更好地适应现代技术环境。在Part I: Java Web Tier部分，章节1介绍了新的Servlet功能，这些更新使Servlet技术与时俱进，能够更好地配合现代技术，例如支持更高级的编程特性，提升了Web应用程序的性能和灵活性。章节2至3则分别关注JavaServer Faces (JSF) 和 Facelets，这两个技术是Java Web界面开发的重要组成部分，它们的更新旨在简化开发过程，提供更直观的用户界面设计。 Part II: Business Logic and Data 部分，第4章讲解了对象关系映射(Object-Relational Mapping, ORM) 的增强，通过Java Persistence API (JPA) 提供了更强大的数据访问和管理能力。章节5至7涉及EJB（Enterprise JavaBeans）在业务逻辑中的应用，包括数据验证、上下文管理和依赖注入，这些都是企业级应用的核心组件，有助于构建可扩展和可靠的系统。 Part III: Web Services and HTML 部分，章节8和9着重于RESTful Web Services的构建，以及WebSockets和JSON的整合，这些技术为Web应用程序提供了实时通信的能力，增强了用户体验。在处理Web服务交互的同时，也强调了HTML技术的革新对现代Web架构的重要性。 Part IV: Under the Covers部分深入探讨了Java EE 7平台的底层技术。章节10介绍了新Java Message Service (JMS) 功能，这有助于处理消息队列和异步通信，提高了系统的并发性和可靠性。章节11重点关注批处理应用、缓存优化和并发编程的最佳实践，这对于提升系统性能至关重要。最后，章节12提供了使用NetBeans开发Java EE 7应用程序的实战指导，便于开发者快速上手。《Introducing Java EE 7: A Look at What’s New》是一本实用的Java EE 7入门和进阶教材，涵盖了从基础技术到实际应用的全方位内容，对于希望通过了解最新特性和最佳实践来提升Java EE开发技能的读者来说，具有很高的参考价值。"

CHAPTER 1 n New Servlet Features

public String getServletInfo() {

return "Short description";

}// </editor-fold>

}

When a user visits this servlet, the servlet will be executed under the specified role. For more information

regarding the configuration of principals and roles in Glassfish, please refer to the online documentation.

Thwarting Session Fixation Attack

It is possible for a web hacker to obtain security IDs used by web sites for authentication purposes. When a malicious

hacker gets ahold of such an identifier, havoc could be wreaked upon a victim’s account because a security ID could

possibly grant a hacker full permissions to the hacked account. Such attacks are known as session fixation attacks.

In Servlet 3.1, session fixation attacks can be thwarted by changing the session ID once a user has successfully

authenticated to the application. The session ID can be changed by calling the new

HttpServletRequest.changeSessionId method after the session has already been created. The new HttpSessionIdListener

interface can be used to implement listener classes that are responsible for changing a session identifier.

The Servlet 3.1 code base has been updated to use the new HttpSessionIdListener as a standard listener. As such,

the following APIs now accept listener classes that implement the HttpSessionIdListener interface:

 addListener(String className)

 <T extends EventListener> void addListener(T t)

 void addListener(Class <? extends EventListener> listenerClass)

 <T extends EventListener> void createListener(Class<T> clazz)

 @WebListener

The following excerpt from the servlet org.javaee.7.chapter01.SessionIdTest demonstrates how to change a

session identifier using this new technique.

…

protected void processRequest(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

response.setContentType("text/html;charset=UTF-8");

PrintWriter out = response.getWriter();

HttpSession session = request.getSession();

try {

/* TODO output your page here. You may use following sample code. */

out.println("<!DOCTYPE html>");

out.println("<html>");

out.println("<head>");

out.println("<title>Servlet SessionIdTest</title>");

out.println("</head>");

out.println("<body>");

out.println("<h1>Servlet SessionIdTest at " + request.getContextPath() + "</h1>");

out.println("<p>the current sesion id is: " + session.getId());

C H A P T E R 2

n n n

JavaServer Faces and

Facelets

The release of Java EE 7 embodies incremental updates for the JavaServer Faces (JSF) API, making it easier to use and

more compliant with modern technology. The JSF web framework originated in the early 2000s, and the web landscape

has changed much since its inception. The incremental releases of JSF 1.x added more features to help build out the

framework, but JSF 1.x was still very much a work in progress that, although it worked fine by itself, was even better

when paired with other third-party frameworks, such as JBoss Seam. When Java EE 6 was released, the JSF 2.0

framework became more self-sufficient and required no third-party frameworks to be fully functional. When utilized

along with the new EJB infrastructure that was part of Java EE 6, JSF 2.0 worked seamlessly but still had a few rough

edges. The JSF 2.1 release repaired bugs and helped smooth some of the rough edges that remained.

The JSF 2.2 release brings with it even more incremental updates that aim to complete the framework even

further, bringing it into alignment with the next generation of web applications using HTML5. This chapter covers

many of the new features that will be important to a wide range of developers. The updated release brings forth better

integration with HTML5, less XML configuration, better page flow, and more security.

View Actions

In JSF 2.1 and prior, it was difficult to invoke action methods within a managed bean unless they were bound to a

command component. Sometimes it makes sense to invoke a method when the page is loading, after the page has been

fully loaded, and so on. In the past, this was done by using a preRenderView event listener, which causes the method

bound within a managed bean to be invoked before the view is rendered. Utilization of the preRenderView event

listener works, but it does not provide the level of control that is required to invoke a method during different phases of

the view life cycle. The preRenderView event listener also requires developers to programmatically check the request

type and work with the navigation handler.

In the JSF 2.2 release, you can use a new technique to invoke action methods within a managed bean during

specified life-cycle events that occur within the view. A new tag, f:viewAction, can be bound to a view, and it can be

incorporated into the JSF life cycle in both non-JSF (initial) and JSF (postback) requests. To use the tag, it must be a

child of the metadata facet. View parameters can be specified within the metadata facet as well, and they will be

available from within the managed bean when the action method is invoked.

The following simple JSF view demonstrates the use of the viewAction, because it will cause the

viewActionManagedBean.viewActionExample() method to be invoked before the view is built:

<html xmlns="http://www.w3.org/1999/xhtml"

xmlns:h="http://xmlns.jcp.org/jsf/html"

xmlns:f="http://xmlns.jcp.org/jsf/core"

CHAPTER 2 n JavaServer Faces and Facelets

xmlns:ui="http://xmlns.jcp.org/jsf/facelets">

<h:head>

<title>Chapter 2 - ViewAction Example</title>

</h:head>

<h:body>

<ui:composition template="../layout/custom_template.xhtml">

<ui:define name="content">

<f:metadata>

<f:viewAction action="#{viewActionManagedBean.viewActionExample()}"/>

</f:metadata>

Please look in the server log to see the message that is being

printed via the viewActionManagedBean.viewActionExample() method.

</ui:define>

</ui:composition>

</h:body>

</html>

In the ViewActionManagedBean controller, the action method named viewActionExample is invoked using the

viewAction. In the following example method, a String is returned, which enables implicit navigation from the action

method. If null is returned, the navigation handler is invoked, but the same view will be rendered again so long as there

are no navigation condition expressions that change the navigation. If a String-based view name is returned, then the

navigation handler will render that view once the method has completed. This can come in handy for situations such as

authentication handling, where an action method is used to check the user’s role, and then the appropriate view is

rendered based upon the authenticated user role.

public String viewActionExample(){

System.out.println("This is being written to the server log when the "

+ "view is accessed...");

return null;

}

As mentioned previously, the viewAction facet can be customized to allow the action method to be invoked at

different stages within the view life cycle. By default, the viewAction will be initiated before postback because they are

expected to execute whether the request was Faces or non-Faces. However, this can be changed by setting the

onPostback attribute of the viewAction tag to true.

<f:viewAction action="#{viewActionManagedBean.viewActionExample()}" onPostback="true"/>

If you need to get even more granular and invoke a view action during a specified life-cycle phase, it is possible

by setting the phase attribute to the phase required. Table 2-1 specifies the different phases along with their phase

value.

Table 2-1. JSF Life-Cycle Phases

Phase

Tag Value

Restore View

RESTORE_VIEW

剩余215页未读，继续阅读

uncleAndyChen

粉丝: 30
资源: 32

Java EE 7新特性深度解析：从Servlet到Web服务

《Apress.Pro.Expression.Blend.4》：精通微软WPF与Silverlight开发的全面指南

2013年Apress《Java EE 7 Recipes》精华指南

精通Web前端：Apress.Pro JavaScript实战指南

Apress.Introducing.Java.EE.7.Jul.2013.epub 完整版本

Apress.Introducing.Visual.CSharp.2010.Nov.2010.pdf

Apress.Introducing.Spring.Framework.A.Primer.

Apress.Introducing.Visual.CSharp.2010.Nov.2010.rar

Apress.Pro.CDI.2.in.Java.EE.8.pdf

Apress.Pro.Ajax.and.Java.Frameworks.Jul.2006.HAPPY.NEW.YEAR

Apress.Pro.Ajax.and.Java.Frameworks.Jul.2006.HAPPY.NEW.YEAR.rar

最新资源