Java EE 7入门指南：Apress出版社

4星 · 超过85%的资源需积分: 10 48 浏览量更新于2024-07-23 收藏 4.85MB PDF 举报

"《Introduction Java EE 7》是由Apress出版社出版的一本关于Java企业级应用开发的入门书籍，涵盖了Java EE 7的新特性，包括Web层、业务逻辑与数据处理、Web服务和HTML，以及底层特性如Java消息服务、批处理、缓存和并发处理等。书中详细介绍了Servlet的新功能、JavaServer Faces和Facelets、表达式语言、对象关系映射（JPA）、企业级Java Bean（EJB）、数据验证、依赖注入等内容，并涉及RESTful Web服务、WebSocket和JSON的构建。此外，还特别提到了使用NetBeans开发Java EE 7应用程序的方法。" 在Java EE 7中，Servlet技术进行了增量升级，引入了新特性，使其与更现代的技术保持同步。这一部分将详细介绍这些新特性，它们可能包括但不限于： 1. **新Servlet特性**：Servlet技术的更新可能涉及增强的请求处理能力、更好的异步处理支持、更高效的过滤器和监听器机制，以及对HTTP/2协议的支持，这使得Servlet能更好地适应高性能和高并发的应用场景。 2. **JavaServer Faces (JSF) 和 Facelets**：JSF是Java EE中的一个组件化用户界面框架，而Facelets是它的视图表示技术。这部分内容可能涵盖JSF 2.x的新特性，如更灵活的组件结构、增强的数据绑定、改进的错误处理和更好的性能。 3. **表达式语言 (EL)**：EL用于简化在Java服务器端获取和设置JavaBean属性。Java EE 7中的EL可能包含更强大的表达式支持、新的函数库和与CDI（上下文和依赖注入）更好的集成。 4. **对象关系映射 (JPA) 和数据访问**：这部分将讲解如何使用JPA 2.x进行数据库操作，包括实体管理、查询语言（JPQL）的改进、多租户支持和对NoSQL数据库的更好支持。 5. **企业级Java Bean (EJB) 与业务逻辑**：EJB是Java EE的核心组件，用于实现可部署的组件模型。Java EE 7中的EJB可能有更简洁的API、更轻量级的会话bean和更好的可测试性。 6. **数据验证**：这部分将介绍如何使用JSR 349（Bean Validation 1.1）来验证对象模型，确保数据的准确性和完整性。 7. **上下文和依赖注入 (CDI)**：CDI提供了一种声明式的方式来管理组件和服务。Java EE 7的CDI可能增加了更多的注解、事件处理和扩展点。 8. **构建RESTful Web服务**：这部分将讲解如何使用JAX-RS API创建RESTful接口，提供HTTP服务，支持GET、POST等HTTP方法。 9. **WebSocket和JSON**：WebSocket提供了全双工的通信协议，而JSON是轻量级的数据交换格式。这两者结合可以实现高效的实时通信，适用于现代Web应用。 10. **Java消息服务 (JMS) 新特性**：Java EE 7可能增强了JMS，包括更好的消息传递模型、更高效的消息队列和发布/订阅模式。 11. **批处理、缓存和并发处理**：这部分将介绍如何在Java EE 7中处理批量数据操作，利用缓存优化性能，以及如何有效地管理并发任务。 12. **使用NetBeans开发Java EE 7应用**：这部分将指导读者如何使用NetBeans IDE创建、调试和部署Java EE 7应用程序，包括项目的设置、代码编辑和测试技巧。通过这本书，读者可以系统地学习Java EE 7的关键技术，并掌握构建现代企业级应用所需的技能。

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页未读，继续阅读

墨晓竹

粉丝: 1
资源: 3

Java EE 7入门指南：Apress出版社

Apress.Begining EJB3 Java EE 7 Edition.2013

Introduction to React(Apress,2015)

Java Collections 作者 APress

JAVA COLLECTION (APress)

Reactive Java Programming(Apress,2016)

Apress.Beginning.Java.EE.7.2013

Java Collections Apress

Genetic Algorithms in Java Basics(Apress,2015)

Apress.Java.EE.7.Recipes.Jun.2013

Jini电子书，Apress出版

最新资源