Seam Framework Experience the Evolution of Java EE 2nd phần 10 pot

• Change the application name as follows: APPENDIX B USING EXAMPLE APPLICATIONS AS TEMPLATES 428 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com... The differenc

Trang 1

B.1 Simple EJB3-Based Web Applications

The integration example is the best starting place for an EJB3-based Seam web

application This is the directory structure of the source project:

To customize the project for your application, follow these steps:

• Add Seam components and other classes in the src directory.

• Add web pages, images, and other web resources in the view directory.

• Edit the build.xml to include any third-party library ﬁles required for your

appli-cation through either the war or eartask For instance, you can include the Ajax4jsf

JARs, as we did in Chapter 20.

• Change the resources/WEB-INF/navigation.xml ﬁle to deﬁne the navigation

rules (i.e., the pageﬂow) in the new application.

• Edit the resources/WEB-INF/pages.xml ﬁle to include page parameters for

RESTful pages (see Chapter 15), page actions, and stateful navigation rules (see

Section 24.5).

• Change the resources/META-INF/persistence.xmlﬁle to specify custom

persis-tence options for the new application, if any (see Chapter 28 for some examples).

• Change the application name as follows:

APPENDIX B USING EXAMPLE APPLICATIONS AS TEMPLATES

428

Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com

Trang 2

• Change the project name "integration" in the build.xml ﬁle to your own

project name (e.g., "mywebapp").

• Change the resources/META-INF/application.xml ﬁle to reﬂect your

application’s context root URL.

• Change the class loader name in resources/META-INF/jboss-app.xml to a

unique name that ﬁts your application.

• Change the JNDI name pattern in the resources/WEB-INF/components.xml

ﬁle to match your application name (i.e., "mywebapp").

JSP versus Facelets XHTML

The integration project template uses Facelets as the presentation technology We

highly recommend using Facelets in your Seam applications (see Section 3.1) Still, if you

really want to use JSP for web pages, you can use the helloworld example as the template.

The setup is similar to the integration project setup we discuss here.

Then run ant in the project directory to build the application The build result is in the

build/jars/mywebapp.ear ﬁle This is the structure of the EAR archive:

If you have unit tests or integration tests for the application, you can put the test cases

(the.java ﬁles) and the testng.xml ﬁle in the test directory in the project An

alter-native components.xml ﬁle is already in the test directory The difference between

test/components.xml and resources/WEB-INF/components.xmlis that the test version

429

B.1 SIMPLE EJB3-BASED WEB APPLICATIONS

Trang 3

does not have the application name in its JNDI pattern (see Section 26.4)—because

the tests are run outside the application server container So if you customize the

resources/WEB-INF/components.xml ﬁle in your application, you must make

the same changes to the test/components.xml ﬁle This is an example test/

Likewise, there is a test version of the persistence.xml ﬁle, which explicitly speciﬁes

the JBoss Transaction Manager lookup in the testing environment You probably also

want to have Hibernate create and drop the database tables on the ﬂy when you start

and ﬁnish your tests.

When you run ant test in the project directory, the build script runs all the tests deﬁned

in the test/testng.xml ﬁle and outputs the test results both to the console and to the

build/testout directory.

For your reference, we list the complete build.xml script here:

430

Trang 4

</path>

</copy>

<! Overwrite the WEB-INF/components.xml >

</copy>

431

B.1 SIMPLE EJB3-BASED WEB APPLICATIONS

Trang 5

<! Overwrite the META-INF/persistence.xml >

Trang 6

B.2 POJO-Based Web Applications

If you want to use Seam POJOs and forgo the EJB3 session beans, you can choose the

jpaproject as the template (see Chapter 4) This project builds the application into a

WAR ﬁle deployable in the J2EE 1.4-compliant proﬁle of the JBoss AS 4.0.5+ With

a little tuning, you can build WAR ﬁles deployable on any J2EE 1.4 application server

(e.g., WebLogic or Sun Application Server).

The following listing shows the structure of the jpa project:

433

B.2 POJO-BASED WEB APPLICATIONS

Trang 7

To customize the project for your application, follow these steps:

• Add Seam components and other classes in the src directory.

• Add web pages, images, and other web resources in the view directory.

• Edit the build.xml ﬁle to include any third-party library ﬁles required for your

application through either the war or eartask For instance, you can include the

Ajax4jsf JARs, as we did in Chapter 20.

• Change the resources/WEB-INF/navigation.xml ﬁle to deﬁne the navigation

rules (i.e., the pageﬂow) in the new application.

• Edit the resources/WEB-INF/pages.xml ﬁle to include page parameters for

RESTful pages (see Chapter 15), page actions, and stateful navigation rules (see

Section 24.5).

• Change the resources/META-INF/persistence.xmlﬁle to specify custom

persis-tence options for the new application, if any (see Chapter 28 for some examples).

For Hibernate applications, modify the resources/hibernate.cfg.xml ﬁle as

needed.

• Change the application name as follows:

• Change the project name "jpa" in the build.xml ﬁle to your own project name

(e.g.,"mywebapp").

• Change the resources/WEB-INF/jboss-web.xml ﬁle to reﬂect your

application’s context root URL as needed.

434

Trang 8

Runant in the project directory to build the build/jars/mywebapp.war application

archive Required application library JARs are included in the WEB-INF/lib directory.

This is the content of the WAR ﬁle:

Running tests in a POJO project is the same as in an EJB3 project The unit tests and

integration tests are located in the test directory Since we have no EJBs here, there

is no need to have a test-speciﬁc version of components.xml for the POJO application.

This is the build.xml script to build the WAR application from the Seam POJO project:

</path>

435

Trang 9

</copy>

<! Overwrite the META-INF/persistence.xml >

Trang 10

Trang 11

For plain Tomcat deployment of Seam POJO applications, refer to the tomcatjpa

example for more details.

B.3 More Complex Applications

The two applications we have discussed in this appendix are simple web applications.

If your application uses advanced Seam features, you must package additional JAR

files and configuration files in the EAR or WAR archives.

• The Drools JARs and conﬁguration ﬁles are needed to support the rule-based web

security framework in Seam Refer to Chapter 22 for more details.

438

Trang 12

• The jBPM JAR and conﬁguration ﬁles are needed to support business processes

and stateful pageﬂows in Seam applications Refer to Chapter 24 for more details.

• PDF support requires the jboss-seam-pdf.jar ﬁle and the itext-*.jar ﬁle

in the WEB-INF/lib directory of the WAR archive Refer to Section 3.4.1 for

more details.

• Facelets-based email template support requires the jboss-seam-mail.jar ﬁle in

the WEB-INF/libdirectory of the WAR archive Refer to Section 3.4.2 for more

details.

• Wiki text support requires the antlr-*.jar ﬁle in the WEB-INF/libdirectory of

the WAR archive Refer to Section 3.4.3 for more details.

439

B.3 MORE COMPLEX APPLICATIONS

Trang 13

This page intentionally left blank

Trang 14

M ost example applications in this book use Ant as the build system Ant is simple

and straightforward However, since the ﬁrst edition of this book, we have seen an

in-creasing adaption of Maven to manage builds Maven provides declarative dependency

management, which ﬁts well with Seam applications since Seam integrates many

third-party libraries and frameworks In this appendix, we “mavenize” the Integration

example application to show you how to use Maven to build Seam applications The

result application is in the maven-ear example.

First, let’s look at the structure of the source code In order to build an EAR application

in Maven, you need to put each component of the EAR in a separate Maven module.

Theejb module builds the EJB JAR; the war builds the WAR; and the ear module

assembles them together into an EAR.

Trang 15

The directory structure here follows Maven’s standard convention For instance, Maven

knows to look for Java sources in src/main/java, classpath resources (e.g., conﬁguration

ﬁles) in src/main/resources, and web content in src/main/webapp That saves us

a lot of time trying to specify and ﬁgure out the source structure.

As you can see, there are no JARs in this structure All the JARs needed for building

and packaging are downloaded from central Maven repositories off the Internet.

The four pom.xml ﬁles are the core of the build system Let’s look at them one by one.

The pom.xml ﬁle in the project root directory deﬁnes the defaults for this project It

speciﬁes things like the group ID of the entire project, which Maven repositories to use,

and the default version number and scope for each dependency It gives us a central

place to view and update the version numbers for each dependency—much better than

the old way of examining each dependency JAR individually If a dependency has the

provided scope, it means that the dependency is provided by the runtime environment

(i.e., the application server) on the classpath Hence, Maven will only include the

provided dependencies in the compiling classpath, but will not include those JARs in

the ﬁnal EAR, WAR, or JAR builds.

Trang 16

APPENDIX C USING MAVEN

Trang 18

The ejb/pom.xml declares the compile-time dependency of the classes in the EJB

module It should declare all its dependencies as provided since those dependencies

will be provided by the application server or included in the EAR Notice that the

de-pendencies here have no version number since they are inherited from the parent pom.xml

in the project root directory.

Trang 19

Thewar/pom.xml declares the dependencies for the WAR module Every dependency

that does not have a provided scope will be included in the WAR’s WEB-INF/lib

directory All the compiled Java classes will be included in WEB-INF/classes.

Trang 20

<! The "provided" dependencies are

only need for compilation >

Trang 21

Theear/pom.xml is executed last in the build process It assembles the JARs together

into an EAR ﬁle All modules and library JARs in the EAR need to be declared as

de-pendencies Then, in the maven-ear-plugin part of the script, we specify the type of

each module and where it should be placed in the EAR archive Maven will build the

application.xml accordingly on the ﬂy Similarly, we can also specify the JBoss

loader in the build so that it will generate a jboss-app.xml for us.

Trang 22

<! The stuff that needs to go in the lib directory.

They will not be included in application.xml >

Maven’spom.xml ﬁles can be much longer than Ant scripts, but their declarative nature

makes them a lot easier to follow and understand.

Now you have the EAR structure of a Maven project It is easy to convert it into a WAR

project for Seam POJO applications or add testing support Check out Maven

documentation for more details.

449

Trang 23

This page intentionally left blank

Trang 24

I n most examples throughout the book, we use JPA (Java Persistence API) for the

persistence logic We use Hibernate as our JPA implementation However, as it is an

open source framework at the forefront of ORM innovation, some of Hibernate’s features

are not yet standardized In particular, JPA does not yet support these features:

• The JPA query language is not as rich as that in Hibernate For instance, JPA does

not support Hibernate’s query-by-criteria or query-by-example.

• Hibernate offers more methods to manage objects with detached state; JPA supports

only one merge() operation in the EntityManager.

• The object type system in Hibernate is much richer than that in JPA.

• Hibernate gives you more control over the size of the extended persistence context.

If you need to use those features, you must use the Hibernate API directly You also

need to use the Hibernate API directly if you are working with legacy Hibernate code

(a large number of XML mapping ﬁles and queries in existing applications belong to

this category) That would mean to use Hibernate Session instead of the JPA

EntityManager in your Seam components The example used in this appendix can be

found in the hibernate example It is a port of the integration example.

D.1 Using the Hibernate API

To use the Hibernate API to manage database objects, we inject a Hibernate Session

instead of an EntityManager into the ManagerPojo class The API methods in the

Trang 25

Hibernate Session are roughly equivalent to those in the EntityManager; they have

only slightly different method names This is the Hibernate version of the ManagerPojo

class:

@Name("manager")

public class ManagerPojo {

@In (required=false) @Out (required=false)

private Person person;

private Person selectedFan;

public String sayHello () {

helloSession.save (person);

return "fans";

}

@Factory("fans")

public void findFans () {

fans = helloSession.createQuery("select p from Person p").list();

public String delete () {

Person toDelete = (Person) helloSession.merge (selectedFan);

Định dạng
Số trang	50
Dung lượng	3,16 MB