JavaServer Pages
Yesterday, you looked at developing Web applications using Java servlets.
Servlets have the advantage of being able to generate the HTML Web page
dynamically. The disadvantage of servlets is the fact that the developer must
generate a lot of HTML formatting information from within Java. Servlets can
be described as large amounts of boring HTML println() statements inter-
spersed with small amounts of interesting Java code.
Servlets make it difficult to differentiate the presentation layer from the logic
layer of an application. This duality of purpose means that servlets do not allow
the roles of HTML designer and Java programmer to be easily separated.
Writing servlets requires the members of the development team to be either
• Java programmers who must learn HTML and Web design
• Web designers who must learn Java
In practice, there are very few Java programmers who make good Web design-
ers, and fewer Web designers who make good Java programmers.
JavaServer Pages are servlets that are written in HTML. Actually, there is a bit
more to it than that, but the Java code on a JSP is usually either non-existent or
very simple, and can be readily understood by non-Java programmers.In today’s lesson, you will learn
• What a JSP is and how its implementation differs from servlets
• The JSP lifecycle—what you have to do and what the Web server will do for you
• How to deploy a JSP
• How to use JavaBeans to hide Java functionality from the JSP
• How to develop a Web application using JSPs
Today’s work builds directly on the knowledge gained yesterday because many of the
mechanisms used in JSPs are the same as servlets.
What is a JSP?
A JSP is just another servlet, and like HTTP servlets, a JSP is a server-side Web compo-
nent that can be used to generate dynamic Web pages.
The fundamental difference between servlets and JSPs is
• Servlets generate HTML from Java code.
• JSPs embed Java code in static HTML.
To illustrate this difference, Listings 13.1 and 13.2 are the same Web page coded as a
servlet and as a JSP, respectively. Each Web page simply reads a parameter called name
from the HTTP request and creates an HTML page displaying the value of the name
parameter. Listing 13.1 shows the servlet, and Listing 13.2 shows the JSP.
LISTING 13.1 Simple Dynamic Page As a Servlet
1: import java.io.*;
2: import javax.servlet.*;
3: import javax.servlet.http.*;
4:
5: public class Hello extends HttpServlet {
6:
7: public void doGet(HttpServletRequest req, HttpServletResponse res)
8: throws ServletException, IOException {
9: res.setContentType (“text/html”);
10: PrintWriter out = res.getWriter();
11: String name = req.getParameter(“name”);
12: out.println (“<HTML>”);
13: out.println (“<HEAD><TITLE>Hello</TITLE></HEAD>”);
14: out.println (“<BODY>”);
15: out.println (“<H1>Hello “ + name + “</H1>”);
16: out.println (“</BODY>”);
17: out.println (“</HTML>”);
18: }
19: }
1: <HTML>
2: <HEAD><TITLE>Hello</TITLE></HEAD>
3: <BODY>
4: <% String name = request.getParameter(“name”); %>
5: <H1>Hello <%=name%> </H1>
6: </BODY>
7: </HTML>
Here you can see that the JSP not only requires far less typing, but a lot of the work is
being done for you. How the JSP achieves the same effect with far less code will soon
become clear.
Separating Roles
With a servlet, the Java programmer was forced to generate the entire HTML. With a
JSP, it is much easier to separate the HTML from the application tasks. With the use of
JavaBeans and JSP tag libraries (covered on Day 14, “JSP Tag Libraries”), this separa-
tion is even more explicit.
Using JSPs, the Web designer can concentrate on the design and development of the
HTML page. When a dynamic element is needed, the developer can use a pre-written
bean or tag library to provide the data. The Java programmer can concentrate on develop-
ing a useful set of beans and tag libraries encapsulating the complex Java required to
retrieve the data from an EJB, a database, or any other data source.
Translation and Execution
JSPs differ from servlets in one other respect. Before execution, a JSP must be converted
into a Java servlet. This done in two stages:
1. The JSP text is translated into Java code.
2. The Java code is compiled into a servlet.
The resulting servlet processes HTTP requests. The translate and compile process is per-
formed once before the first HTTP request can be processed. The JSP lifecycle is cov-
ered in more detail later.
2014年4月16日 星期三
2014年4月14日 星期一
Bean Managed Transaction Demarcation
If an EJB is deployed using bean managed transaction demarcation (here referred to as
BMTD, though this abbreviation isn’t used in the EJB specification itself), the EJB con-
tainer allows the bean to obtain a reference to a javax.transaction.UserTransaction
object using the EJBContext. You can see this in Figure 8.3.
Motivation and Restrictions
An EJB might need to be deployed under BMTD if the conditions on which a transaction
is started depend on some programmatic condition. It could be that one method starts the
transaction and another method completes the transaction.
However, the cases where BMTD is needed are few and far between. Indeed, they are so
rare that the EJB specification limits BMTD to Session beans. Entity beans can only be
deployed with CMTD. This makes sense because Entity beans represent persistent trans-
actional data; the transaction context should be as deterministic as possible.
Moreover, if a stateless Session bean starts a transaction, it must also commit that trans-
action before the method completes. After all, the stateless Session bean will have no
memory of the client that just invoked its method after that method completes, so one
cannot expect that the transaction context is somehow miraculously preserved. If you
write a BMTD stateless Session bean that does not commit its own transaction, the EJB
container will rollback the transaction and throw an exception back to the client
(java.rmi.RemoteException for remote clients, or javax.ejb.EJBException for local).
Indeed, even with stateful Session beans, there is a restriction. Any current transaction in
progress when the BMTD Session bean is called will be suspended by the EJB container,
not propagated to the BMTD bean. It is possible that, from the bean’s perspective, there
is a current transaction, but that would refer to any transaction not committed when a
method on that bean was last called.
Using the Java Transaction API
When a Session bean is deployed under BMTD, there is an implementation choice as to
how it should manage its transactions. If interacting solely with an RDBMS, the Session
bean can manage the transactions directly through the JDBC API. Alternatively, it can
use the Java Transaction API, defined by the classes and interfaces in the javax.trans-
action and the javax.transaction.xa packages. The latter is to be preferred, if only
because transactional access to Java Messaging Service resources (you’ll be learning
more about these tomorrow and the day after) can only be performed through the JTA
API. Equally, servlets can also use the JTA API.
For a Session bean to start a transaction, it should first call the getUserTransaction()
method of its SessionContext. You’ll recall that this was the method that throws an
exception under CMTD, but it is the centerpiece of transaction control under BMTD.
Obtaining a UserTransaction does not mean that a transaction has been started. Rather,
it must be started using the begin() method. The transaction can then be completed
using either the commit() or the rollback() method. The current status can also be
obtained using getStatus(). This returns an int whose meaning is defined by the
constants in the javax.transaction.Status interface. Some of the most common status
values are shown in Table 8.2.
BMTD, though this abbreviation isn’t used in the EJB specification itself), the EJB con-
tainer allows the bean to obtain a reference to a javax.transaction.UserTransaction
object using the EJBContext. You can see this in Figure 8.3.
Motivation and Restrictions
An EJB might need to be deployed under BMTD if the conditions on which a transaction
is started depend on some programmatic condition. It could be that one method starts the
transaction and another method completes the transaction.
However, the cases where BMTD is needed are few and far between. Indeed, they are so
rare that the EJB specification limits BMTD to Session beans. Entity beans can only be
deployed with CMTD. This makes sense because Entity beans represent persistent trans-
actional data; the transaction context should be as deterministic as possible.
Moreover, if a stateless Session bean starts a transaction, it must also commit that trans-
action before the method completes. After all, the stateless Session bean will have no
memory of the client that just invoked its method after that method completes, so one
cannot expect that the transaction context is somehow miraculously preserved. If you
write a BMTD stateless Session bean that does not commit its own transaction, the EJB
container will rollback the transaction and throw an exception back to the client
(java.rmi.RemoteException for remote clients, or javax.ejb.EJBException for local).
Indeed, even with stateful Session beans, there is a restriction. Any current transaction in
progress when the BMTD Session bean is called will be suspended by the EJB container,
not propagated to the BMTD bean. It is possible that, from the bean’s perspective, there
is a current transaction, but that would refer to any transaction not committed when a
method on that bean was last called.
Using the Java Transaction API
When a Session bean is deployed under BMTD, there is an implementation choice as to
how it should manage its transactions. If interacting solely with an RDBMS, the Session
bean can manage the transactions directly through the JDBC API. Alternatively, it can
use the Java Transaction API, defined by the classes and interfaces in the javax.trans-
action and the javax.transaction.xa packages. The latter is to be preferred, if only
because transactional access to Java Messaging Service resources (you’ll be learning
more about these tomorrow and the day after) can only be performed through the JTA
API. Equally, servlets can also use the JTA API.
For a Session bean to start a transaction, it should first call the getUserTransaction()
method of its SessionContext. You’ll recall that this was the method that throws an
exception under CMTD, but it is the centerpiece of transaction control under BMTD.
Obtaining a UserTransaction does not mean that a transaction has been started. Rather,
it must be started using the begin() method. The transaction can then be completed
using either the commit() or the rollback() method. The current status can also be
obtained using getStatus(). This returns an int whose meaning is defined by the
constants in the javax.transaction.Status interface. Some of the most common status
values are shown in Table 8.2.
JAVA : Transactions and Persistence
Overview of Transactions
If you’ve used RDBMS before, or completed a Computer Studies course or read any
other J2EE book, you’ve probably read a section like this one already. But read on any-
way, if only to be acquainted with some of the J2EE terminology that is used in this
arena.
A transaction is an atomic unit of work:
• Atomic unit means indivisible—either every step within the transaction completes
or none of them do.
• Work here usually means some modification to data within a persistent data store.
In RDBMS terms, this means one or more INSERT, UPDATE, or DELETEs. However,
strictly speaking, it also applies to reading of data through SELECT statements.
For a persistent data store to support transactions, it must pass the so-called “ACID” test:
• Atomic—The transaction is indivisible; the data store must ensure this is true.
• Consistent—The data store goes from one consistent point to another. Before the
transaction, the data store is consistent; afterwards, it is still consistent.
The age-old example is of transferring money between bank accounts. This will
involve two UPDATEs, one decrementing the balance of account #1 and the other
incrementing the balance of account #2. If only one UPDATE occurs, the transaction
is not atomic, and the data store is no longer in a consistent state.
• Isolation—The data store gives the illusion that the transaction is being performed
in isolation. Enterprise applications have many concurrent users who are all per-
forming transactions at the same time, so behind the scenes, the data store uses tech-
niques, such as locks, to serialize access to the contended data where necessary.
• Durability—If a transaction completes, any changes made to the data as a result of
that transaction must be durable. In other words, if the power were to fail a mil-
lisecond after the transaction has completed, the change must still be there when
power is reconnected.
Many data stores use transaction logs to address this requirement. The transaction
log holds a journal of changes made to the actual data. When the transaction com-
pletes, the log is written to disk, although the actual data need not be.
Many data stores allow transactions to be started explicitly using a syntax such as the
following:
begin transaction t1
where t1 is the (optional) name transaction. Transactions are completed using either
commit (make changes permanent) or rollback (undo all changes made in the transac-
tion, and revert all data back to the state before the transaction began). Many data stores
will use
commit transaction t1
and
rollback transaction t1
In the EJB specification, these two responsibilities are split. In principle, you can think
of the EJB container as acting as the transaction manager, and the persistent data store
acting only as the resource manager. The term transaction coordinator is sometimes used
instead of transaction manager because there could be more than one resource whose
transactions are being coordinated.
Splitting the responsibilities of transaction management and resource management has
two consequences. For the bean provider, it means that to start a transaction, the bean
must interact both with the EJB container and with the persistent data store. The former
interaction is largely implicit because it is configured through the deployment descriptor
(and as you know, the latter interaction is implicit if CMP Entity beans are used). The
other consequence is that, for the persistent data store, it must defer all transaction con-
trol responsibility up to the EJB container. Behind the scenes, there is some quite sophis-
ticated communication going on; you’ll learn a little about this activity later on today.
If you’ve used RDBMS before, or completed a Computer Studies course or read any
other J2EE book, you’ve probably read a section like this one already. But read on any-
way, if only to be acquainted with some of the J2EE terminology that is used in this
arena.
A transaction is an atomic unit of work:
• Atomic unit means indivisible—either every step within the transaction completes
or none of them do.
• Work here usually means some modification to data within a persistent data store.
In RDBMS terms, this means one or more INSERT, UPDATE, or DELETEs. However,
strictly speaking, it also applies to reading of data through SELECT statements.
For a persistent data store to support transactions, it must pass the so-called “ACID” test:
• Atomic—The transaction is indivisible; the data store must ensure this is true.
• Consistent—The data store goes from one consistent point to another. Before the
transaction, the data store is consistent; afterwards, it is still consistent.
The age-old example is of transferring money between bank accounts. This will
involve two UPDATEs, one decrementing the balance of account #1 and the other
incrementing the balance of account #2. If only one UPDATE occurs, the transaction
is not atomic, and the data store is no longer in a consistent state.
• Isolation—The data store gives the illusion that the transaction is being performed
in isolation. Enterprise applications have many concurrent users who are all per-
forming transactions at the same time, so behind the scenes, the data store uses tech-
niques, such as locks, to serialize access to the contended data where necessary.
• Durability—If a transaction completes, any changes made to the data as a result of
that transaction must be durable. In other words, if the power were to fail a mil-
lisecond after the transaction has completed, the change must still be there when
power is reconnected.
Many data stores use transaction logs to address this requirement. The transaction
log holds a journal of changes made to the actual data. When the transaction com-
pletes, the log is written to disk, although the actual data need not be.
Many data stores allow transactions to be started explicitly using a syntax such as the
following:
begin transaction t1
where t1 is the (optional) name transaction. Transactions are completed using either
commit (make changes permanent) or rollback (undo all changes made in the transac-
tion, and revert all data back to the state before the transaction began). Many data stores
will use
commit transaction t1
and
rollback transaction t1
In the EJB specification, these two responsibilities are split. In principle, you can think
of the EJB container as acting as the transaction manager, and the persistent data store
acting only as the resource manager. The term transaction coordinator is sometimes used
instead of transaction manager because there could be more than one resource whose
transactions are being coordinated.
Splitting the responsibilities of transaction management and resource management has
two consequences. For the bean provider, it means that to start a transaction, the bean
must interact both with the EJB container and with the persistent data store. The former
interaction is largely implicit because it is configured through the deployment descriptor
(and as you know, the latter interaction is implicit if CMP Entity beans are used). The
other consequence is that, for the persistent data store, it must defer all transaction con-
trol responsibility up to the EJB container. Behind the scenes, there is some quite sophis-
ticated communication going on; you’ll learn a little about this activity later on today.
2014年4月13日 星期日
馬航副機師疑打手機求救
在馬航MH370客機失蹤五個星期仍然下落不明之際，馬來西亞國營《新海峽時報》周六表示調查有新發現，指客機三月八日凌晨從雷達屏幕消失後，副機師法里克趁着客機在檳城附近上空低空飛行時，曾在機上嘗試用手機撥打電話，惟電話通訊突然中斷，可能是因為客機當時以高速遠離地面通訊塔。
報道引述消息人士稱，MH370失聯後曾經低空飛行，當時它在大馬西岸檳城附近上空的低空飛行高度，足以讓最近的地面通訊塔接收到機上手機訊號。調查人員正在深入調查這一項新發現，冀能完整呈現MH370從雷達消失前一刻，機上發生過的事情。MH370最後從軍方雷達屏幕消失時，位置在檳城西北約三百二十公里。專家表示，通訊塔可接收到從七千呎高度傳來的手機訊號。
對於法里克的電話通訊突然中斷，消息人士認為原因可能是MH370急速飛離接收到機上手機訊號的通訊塔後，沒有飛入另一處通訊塔所在的訊號覆蓋區。在這篇題為「絕望的求救電話」的頭版報道中，沒提到法里克要打給誰，因為消息人士不肯泄露調查細節。
不過，《新海峽時報》也引述另一批接近調查的消息人士稱，法里克的手機在MH370起飛前已中斷連綫，在飛機偏離航道轉變方向至消失之間的一段時間內，法里克的手機又重新駁綫，但無法肯定他是否真的有打出電話。所謂「重新駁綫」，未必一定顯示有人打出電話，可能只是飛機上有人再次開啟手機，而地面通訊塔接收到有關手機訊號。
當局也追查法里克的電話記錄，顯示他最後通話的人是他平日經常聯絡的，那個人的電話號碼在他的撥電記錄中頻繁出現。法里克的一名親戚上周一表示，法里克與母親之間的關係密切，如果他在飛機消失前真的打過電話，可能是聯絡她。
《新海峽時報》也表示，法里克最後一次以智能手機軟件WhatsApp Messenger通訊，是三月七日深夜十一時半，即MH370起飛之前一小時多，當晚MH370於三月八日零時四十一分從吉隆坡國際機場起飛。
大馬代理交通部長希山慕丁回應該篇報道表示：「除非我們經過查證，否則無法談論這些報道。」他說：「如果真有其事，我們應早就知道了。」
調查人員於上月指MH370飛出馬來西亞領空時，不但蓄意改變航道，並以人手關閉機上通訊系統，令警方馬上展開刑事調查。MH370為何失聯仍是一個謎，多方作出的推測「各說各話」，有推測指是劫機或恐襲，甚至有人認為是機師蓄意墜機自殺。
Java EJB introduction
What Is an EJB?
In a typical J2EE application, Enterprise JavaBeans (EJBs) contain the application’s business
logic and live business data. Although it is possible to use standard Java objects to
contain your business logic and business data, using EJBs addresses many of the issues
you would find by using simple Java objects, such as scalability, lifecycle management,
and state management.
Beans, Clients, Containers, and Servers
An EJB is essentially a managed component that is created, controlled, and destroyed by
the J2EE container in which it lives. This control allows the container to control the
number of EJBs currently in existence and the resources they are using, such as memory
and database connections. Each container will maintain a pool of EJB instances that are
ready to be assigned to a client. When a client no longer needs an EJB, the EJB instance
will be returned to the pool and all of its resources will be released. At times of heavy
load, even EJB instances that are still in use by clients will be returned to the pool so
they can service other clients. When the original client makes another request of its EJB,
the container will reconstitute the original EJB instance to service the request. This pooling
and recycling of EJB instances means that a few EJB instances, and the resources
they use, can be shared between many clients. This maximizes the scalability of the EJBbased
application. The EJB lifecycle is discussed further on Days 5 and 6.
The client that uses the EJB instance does not need to know about all of this work by the
container. As far as the client is concerned, it is talking to a remote component that supports
defined business methods. How those methods are implemented and any magic performed
by the container, such as just-in-time instantiation of that specific component
instance, are entirely transparent to the client part of the application.
The EJB benefits from certain services provided by the container, such as automatic
security, automatic transactions, lifecycle management, and so on. To do this, the EJB
must conform to certain rules and implement an appropriate interface that allows the
container to manage the component. The EJB is packaged with configuration information
that indicates the component’s requirements, such as transaction and security requirements.
The container will then use this information to perform authentication and control
transactions on behalf of the component—the component does not have to contain code
to perform such tasks.
The primary purpose of the container is to control and provide services for the EJBs it
contains. When it needs to use some underlying functionality, such as creating a transaction
on behalf of a bean, it uses the facilities of the underlying EJB server. The EJB
server is the base set of services on top of which the container runs. Different types of
EJB will run in different containers, but many different EJB containers can run on a single
EJB server. EJB servers are generally delivered as part of a J2EE-compliant application
server (examples include BEA WebLogic and IBM WebSphere). You will install and
run the application server, which will provide the underlying services required of an EJB
server and will host EJB containers.
The EJB Landscape
As you have seen, the J2EE Blueprints (http://java.sun.com/blueprints/enterprise/
index.html) define a target architecture for a typical J2EE-based application. In
this architecture, EJBs live in the middle tier and are used by other application components
that live in the presentation tier. Although it is possible that both of these logical
tiers will reside on the same computer, it is most likely that they will reside on different
machines. This means that an EJB will usually have to be made available to remote
clients.
To offer services to remote clients, EJBs will export their services as RMI remote
interfaces. RMI allows you to define distributed interfaces in Java. There are certain
caveats on doing this, not only at the implementation level (such as declaring that
RemoteExceptions may be thrown when calling a method on an EJB) but also at the
design level. Designing remote interfaces is a skill in itself, which will be explored as
you progress through topics in this book, such as EJBs and J2EE Patterns.
Because they must use an RMI-based interface to access the functionality of the EJB, the
clients of an EJB must have some programming functionality. This means that they are
typically either “thick” clients that provide a GUI interface or Web-server components
that deliver HTML interfaces to “thin” clients. The different types of client are explored
in more detail shortly.
In the other direction, EJBs themselves will make use of data sources, such as databases
and mainframe systems, to perform the required business logic. Access to such data and
services can be through a JDBC database connection, a J2EE Connector, another EJB, or
a dedicated server or class of some form.
In a typical J2EE application, Enterprise JavaBeans (EJBs) contain the application’s business
logic and live business data. Although it is possible to use standard Java objects to
contain your business logic and business data, using EJBs addresses many of the issues
you would find by using simple Java objects, such as scalability, lifecycle management,
and state management.
Beans, Clients, Containers, and Servers
An EJB is essentially a managed component that is created, controlled, and destroyed by
the J2EE container in which it lives. This control allows the container to control the
number of EJBs currently in existence and the resources they are using, such as memory
and database connections. Each container will maintain a pool of EJB instances that are
ready to be assigned to a client. When a client no longer needs an EJB, the EJB instance
will be returned to the pool and all of its resources will be released. At times of heavy
load, even EJB instances that are still in use by clients will be returned to the pool so
they can service other clients. When the original client makes another request of its EJB,
the container will reconstitute the original EJB instance to service the request. This pooling
and recycling of EJB instances means that a few EJB instances, and the resources
they use, can be shared between many clients. This maximizes the scalability of the EJBbased
application. The EJB lifecycle is discussed further on Days 5 and 6.
The client that uses the EJB instance does not need to know about all of this work by the
container. As far as the client is concerned, it is talking to a remote component that supports
defined business methods. How those methods are implemented and any magic performed
by the container, such as just-in-time instantiation of that specific component
instance, are entirely transparent to the client part of the application.
The EJB benefits from certain services provided by the container, such as automatic
security, automatic transactions, lifecycle management, and so on. To do this, the EJB
must conform to certain rules and implement an appropriate interface that allows the
container to manage the component. The EJB is packaged with configuration information
that indicates the component’s requirements, such as transaction and security requirements.
The container will then use this information to perform authentication and control
transactions on behalf of the component—the component does not have to contain code
to perform such tasks.
The primary purpose of the container is to control and provide services for the EJBs it
contains. When it needs to use some underlying functionality, such as creating a transaction
on behalf of a bean, it uses the facilities of the underlying EJB server. The EJB
server is the base set of services on top of which the container runs. Different types of
EJB will run in different containers, but many different EJB containers can run on a single
EJB server. EJB servers are generally delivered as part of a J2EE-compliant application
server (examples include BEA WebLogic and IBM WebSphere). You will install and
run the application server, which will provide the underlying services required of an EJB
server and will host EJB containers.
The EJB Landscape
As you have seen, the J2EE Blueprints (http://java.sun.com/blueprints/enterprise/
index.html) define a target architecture for a typical J2EE-based application. In
this architecture, EJBs live in the middle tier and are used by other application components
that live in the presentation tier. Although it is possible that both of these logical
tiers will reside on the same computer, it is most likely that they will reside on different
machines. This means that an EJB will usually have to be made available to remote
clients.
To offer services to remote clients, EJBs will export their services as RMI remote
interfaces. RMI allows you to define distributed interfaces in Java. There are certain
caveats on doing this, not only at the implementation level (such as declaring that
RemoteExceptions may be thrown when calling a method on an EJB) but also at the
design level. Designing remote interfaces is a skill in itself, which will be explored as
you progress through topics in this book, such as EJBs and J2EE Patterns.
Because they must use an RMI-based interface to access the functionality of the EJB, the
clients of an EJB must have some programming functionality. This means that they are
typically either “thick” clients that provide a GUI interface or Web-server components
that deliver HTML interfaces to “thin” clients. The different types of client are explored
in more detail shortly.
In the other direction, EJBs themselves will make use of data sources, such as databases
and mainframe systems, to perform the required business logic. Access to such data and
services can be through a JDBC database connection, a J2EE Connector, another EJB, or
a dedicated server or class of some form.
隱私權政策
DoubleClick Cookie
Google 會在夥伴網站 (例如顯示 AdSense 廣告或加入 Google 認證廣告聯播網的網站) 上刊登的廣告中，使用 DoubleClick Cookie。使用者在夥伴網站上查看或按下廣告後，系統可能會在他的瀏覽器中放置一個 Cookie。
隱私權政策
- 第三方廠商 (包括 Google) 會根據使用者先前在您網站的造訪紀錄，使用 Cookie 來放送廣告。
- Google 和其夥伴會運用 DoubleClick Cookie，根據使用者在您的網站和/或其他網站上瀏覽的內容，對使用者放送合適的廣告。
- 使用者可以到廣告設定中，選擇停用按照興趣顯示廣告的 DoubleClick Cookie (或者，您也可以將使用者帶往aboutads.info，在該處選擇停止某個第三方供應商使用 Cookie 按照興趣顯示廣告)。
- 讓網站訪客知道有第三方供應商和廣告聯播網在您的網站上放送廣告。
- 提供相關供應商和廣告聯播網的網站連結。
- 讓使用者知道他們可以前往上述網站，拒絕系統以 Cookie 按照興趣顯示廣告 (如果供應商或廣告聯播網提供這項功能)。或者，您也可以將使用者帶往 aboutads.info，然後在該處選擇停止某些第三方供應商使用 Cookie 按照興趣顯示廣告。
Java: Naming Conventions
Naming Conventions
Each naming service has its own mechanism for supplying a name. Perhaps the most
familiar naming convention is that of DNS, where every machine connected to the
Internet has a unique name and address. Most readers should recognize the following as
a host name used by DNS:
www.samspublishing.com
In contrast, LDAP names are based on the X.500 standard and use distinguished names
that look like the following fictitious example:
cn=Martin Bond, ou=Authors, o=SAMS, c=us
This format will also be familiar to users of Microsoft’s Active Directory service, whose
naming system is also based on X.500 but uses a forward slash to separate the various
name components:
cn=Martin Bond/ou=Authors/o=SAMS/c=us
These last two naming conventions have similarities in that they are both hierarchically
structured with the most specific name occurring first and the most general name (or
context) occurring last.
JNDI provides classes that support creating and manipulating structured names; but most
programmers will use simple strings that JNDI passes on to the underlying service with
minimal interpretation.
Some JNDI Service Providers may use names that are case sensitive, and some service
providers may not, it all depends on the underlying technology and environment. To
maintain portability of your applications, it is always best to avoid names that differ only
by letter case and also ensure that names are always spelled in a consistent manner.
Using JNDI
JNDI is a standard component of JDK 1.3 and is, therefore, also part of J2EE 1.3. JNDI
is also included in J2EE 1.2 and is available as a standard Java extension for JDK 1.2
and earlier.
While developing code, the program’s CLASSPATH must include the location of the JNDI
class libraries. As long as the JAVA_HOME environment variable has been set up, the JNDI
classes will be available to the Java compiler.
Running a JNDI-aware program requires a JNDI service to be running and the classes for
that service to be available to the program. Typically, this requires the CLASSPATH to
include one or more JAR files provided by the JNDI provider or a J2EE server vendor.
For implementation-specific details, see the vendor’s documentation.
By default, running a J2EE server starts a naming service on the same machine. If the
default behavior isn’t required, you must change the J2EE server configuration to use an
existing JNDI server.
Using Sun Microsystems’ J2EE Reference
Implementation
Using JNDI with Sun Microsystems’ J2EE Reference Implementation (RI) is straightforward.
Ensure that
• The J2EE_HOME variable exists
• The CLASSPATH variable includes the j2ee.jar file from the lib directory of the
J2EE home directory
Examples of how to do this both for Windows and for Unix are shown in this section.
J2EE RI for Windows
Under systems running Microsoft Windows NT or 2000, you can set the class path interactively
with the following:
Set CLASSPATH=%J2EE_HOME%\lib\j2ee.jar;%CLASSPATH%
Typically, it is better to set the class path as a system-wide environment variable (via the
My Computer properties dialog). A suitable value is as follows:
.;%J2EE_HOME%\lib\j2ee.jar
The class path can also include additional JAR files and directories for other Java components.
It is important to define the current directory (.) in the class path; otherwise, the Java
compiler and runtime systems will not find the classes for the program being developed.
J2EE RI for Linux and Unix
Under Linux and Unix, set the class path with the following:
CLASSPATH=$J2EE_HOME/lib/j2ee.jar:$CLASSPATH
Starting the JNDI Server
Startup the J2EE RI server, as Day 2, “The J2EE Platform and Roles,” described, and the
JNDI server will start at the same time. You start the J2EE server by entering the following
command from a command-line window:
j2ee –verbose
The J2EE server will run in that window until you close the window down or enter the
following shutdown command from another command-line window:
j2ee -stop
Obtaining an Initial Context
The first step in using the JNDI name service is to get a context in which to add or find
names. The context that represents the entire namespace is called the Initial Context and
is represented by a class called javax.naming.InitialContext and is a sub-class of the
javax.naming.Context class.
A Context object represents a context that you can use to look up objects or add new
objects to the namespace. You can also interrogate the context to get a list of objects
bound to that context.
The javax.naming package contains all the simple JNDI classes. Sub-packages within
the javax.naming package provide additional JNDI functionality, such as directorybased
features like attributes.
The following code creates an initial context using the default JNDI service information:
Context ctx = new InitialContext();
If something goes wrong when creating the initial context, a NamingException is thrown.
Each naming service has its own mechanism for supplying a name. Perhaps the most
familiar naming convention is that of DNS, where every machine connected to the
Internet has a unique name and address. Most readers should recognize the following as
a host name used by DNS:
www.samspublishing.com
In contrast, LDAP names are based on the X.500 standard and use distinguished names
that look like the following fictitious example:
cn=Martin Bond, ou=Authors, o=SAMS, c=us
This format will also be familiar to users of Microsoft’s Active Directory service, whose
naming system is also based on X.500 but uses a forward slash to separate the various
name components:
cn=Martin Bond/ou=Authors/o=SAMS/c=us
These last two naming conventions have similarities in that they are both hierarchically
structured with the most specific name occurring first and the most general name (or
context) occurring last.
JNDI provides classes that support creating and manipulating structured names; but most
programmers will use simple strings that JNDI passes on to the underlying service with
minimal interpretation.
Some JNDI Service Providers may use names that are case sensitive, and some service
providers may not, it all depends on the underlying technology and environment. To
maintain portability of your applications, it is always best to avoid names that differ only
by letter case and also ensure that names are always spelled in a consistent manner.
Using JNDI
JNDI is a standard component of JDK 1.3 and is, therefore, also part of J2EE 1.3. JNDI
is also included in J2EE 1.2 and is available as a standard Java extension for JDK 1.2
and earlier.
While developing code, the program’s CLASSPATH must include the location of the JNDI
class libraries. As long as the JAVA_HOME environment variable has been set up, the JNDI
classes will be available to the Java compiler.
Running a JNDI-aware program requires a JNDI service to be running and the classes for
that service to be available to the program. Typically, this requires the CLASSPATH to
include one or more JAR files provided by the JNDI provider or a J2EE server vendor.
For implementation-specific details, see the vendor’s documentation.
By default, running a J2EE server starts a naming service on the same machine. If the
default behavior isn’t required, you must change the J2EE server configuration to use an
existing JNDI server.
Using Sun Microsystems’ J2EE Reference
Implementation
Using JNDI with Sun Microsystems’ J2EE Reference Implementation (RI) is straightforward.
Ensure that
• The J2EE_HOME variable exists
• The CLASSPATH variable includes the j2ee.jar file from the lib directory of the
J2EE home directory
Examples of how to do this both for Windows and for Unix are shown in this section.
J2EE RI for Windows
Under systems running Microsoft Windows NT or 2000, you can set the class path interactively
with the following:
Set CLASSPATH=%J2EE_HOME%\lib\j2ee.jar;%CLASSPATH%
Typically, it is better to set the class path as a system-wide environment variable (via the
My Computer properties dialog). A suitable value is as follows:
.;%J2EE_HOME%\lib\j2ee.jar
The class path can also include additional JAR files and directories for other Java components.
It is important to define the current directory (.) in the class path; otherwise, the Java
compiler and runtime systems will not find the classes for the program being developed.
J2EE RI for Linux and Unix
Under Linux and Unix, set the class path with the following:
CLASSPATH=$J2EE_HOME/lib/j2ee.jar:$CLASSPATH
Starting the JNDI Server
Startup the J2EE RI server, as Day 2, “The J2EE Platform and Roles,” described, and the
JNDI server will start at the same time. You start the J2EE server by entering the following
command from a command-line window:
j2ee –verbose
The J2EE server will run in that window until you close the window down or enter the
following shutdown command from another command-line window:
j2ee -stop
Obtaining an Initial Context
The first step in using the JNDI name service is to get a context in which to add or find
names. The context that represents the entire namespace is called the Initial Context and
is represented by a class called javax.naming.InitialContext and is a sub-class of the
javax.naming.Context class.
A Context object represents a context that you can use to look up objects or add new
objects to the namespace. You can also interrogate the context to get a list of objects
bound to that context.
The javax.naming package contains all the simple JNDI classes. Sub-packages within
the javax.naming package provide additional JNDI functionality, such as directorybased
features like attributes.
The following code creates an initial context using the default JNDI service information:
Context ctx = new InitialContext();
If something goes wrong when creating the initial context, a NamingException is thrown.
訂閱：
文章 (Atom)