Java Servlet technology provides dynamic, user-oriented content in web applications using a request-response programming model.
The following topics are addressed here:
A servlet is a Java programming language class used to extend the capabilities of servers that host applications accessed by means of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers. For such applications, Java Servlet technology defines HTTP-specific servlet classes.
The javax.servlet
and javax.servlet.http
packages provide interfaces and classes for writing servlets. All servlets must implement the Servlet
interface, which defines lifecycle methods. When implementing a generic service, you can use or extend the GenericServlet
class provided with the Java Servlet API. The HttpServlet
class provides methods, such as doGet
and doPost
, for handling HTTP-specific services.
The lifecycle of a servlet is controlled by the container in which the servlet has been deployed. When a request is mapped to a servlet, the container performs the following steps.
If an instance of the servlet does not exist, the web container:
Loads the servlet class
Creates an instance of the servlet class
Initializes the servlet instance by calling the init
method (initialization is covered in Creating and Initializing a Servlet)
The container invokes the service
method, passing request and response objects. Service methods are discussed in Writing Service Methods.
If it needs to remove the servlet, the container finalizes the servlet by calling the servlet's destroy
method. For more information, see Finalizing a Servlet.
You can monitor and react to events in a servlet's lifecycle by defining listener objects whose methods get invoked when lifecycle events occur. To use these listener objects, you must define and specify the listener class.
You define a listener class as an implementation of a listener interface. Table 17-1 lists the events that can be monitored and the corresponding interface that must be implemented. When a listener method is invoked, it is passed an event that contains information appropriate to the event. For example, the methods in the HttpSessionListener
interface are passed an HttpSessionEvent
, which contains an HttpSession
.
Table 17-1 Servlet Lifecycle Events
| Object | Event | Listener Interface and Event Class |
|---|---|---|
|
Web context |
Initialization and destruction |
|
|
Web context |
Attribute added, removed, or replaced |
|
|
Session |
Creation, invalidation, activation, passivation, and timeout |
|
|
Session |
Attribute added, removed, or replaced |
|
|
Request |
A servlet request has started being processed by web components |
|
|
Request |
Attribute added, removed, or replaced |
|
Use the @WebListener
annotation to define a listener to get events for various operations on the particular web application context. Classes annotated with @WebListener
must implement one of the following interfaces:
javax.servlet.ServletContextListener javax.servlet.ServletContextAttributeListener javax.servlet.ServletRequestListener javax.servlet.ServletRequestAttributeListener javax.servlet..http.HttpSessionListener javax.servlet..http.HttpSessionAttributeListener
For example, the following code snippet defines a listener that implements two of these interfaces:
import javax.servlet.ServletContextAttributeListener; import javax.servlet.ServletContextListener; import javax.servlet.annotation.WebListener; @WebListener() public class SimpleServletListener implements ServletContextListener, ServletContextAttributeListener { ...
Any number of exceptions can occur when a servlet executes. When an exception occurs, the web container generates a default page containing the following message:
A Servlet Exception Has Occurred
But you can also specify that the container should return a specific error page for a given exception.
Web components, like most objects, usually work with other objects to accomplish their tasks. Web components can do so by doing the following.
Using private helper objects (for example, JavaBeans components).
Sharing objects that are attributes of a public scope.
Using a database.
Invoking other web resources. The Java Servlet technology mechanisms that allow a web component to invoke other web resources are described in Invoking Other Web Resources.
Collaborating web components share information by means of objects that are maintained as attributes of four scope objects. You access these attributes by using the getAttribute
and setAttribute
methods of the class representing the scope. Table 17-2 lists the scope objects.
Table 17-2 Scope Objects
| Scope Object | Class | Accessible From |
|---|---|---|
|
Web context |
|
Web components within a web context. See Accessing the Web Context. |
|
Session |
|
Web components handling a request that belongs to the session. See Maintaining Client State. |
|
Request |
Subtype of |
Web components handling the request. |
|
Page |
|
The JSP page that creates the object. |
In a multithreaded server, shared resources can be accessed concurrently. In addition to scope object attributes, shared resources include in-memory data, such as instance or class variables, and external objects, such as files, database connections, and network connections.
Concurrent access can arise in several situations.
Multiple web components accessing objects stored in the web context.
Multiple web components accessing objects stored in a session.
Multiple threads within a web component accessing instance variables. A web container will typically create a thread to handle each request. To ensure that a servlet instance handles only one request at a time, a servlet can implement the SingleThreadModel
interface. If a servlet implements this interface, no two threads will execute concurrently in the servlet's service method. A web container can implement this guarantee by synchronizing access to a single instance of the servlet or by maintaining a pool of web component instances and dispatching each new request to a free instance. This interface does not prevent synchronization problems that result from web components' accessing shared resources, such as static class variables or external objects.
When resources can be accessed concurrently, they can be used in an inconsistent fashion. You prevent this by controlling the access using the synchronization techniques described in the Threads lesson at http://docs.oracle.com/javase/tutorial/essential/concurrency/
.
Use the @WebServlet
annotation to define a servlet component in a web application. This annotation is specified on a class and contains metadata about the servlet being declared. The annotated servlet must specify at least one URL pattern. This is done by using the urlPatterns
or value
attribute on the annotation. All other attributes are optional, with default settings. Use the value
attribute when the only attribute on the annotation is the URL pattern; otherwise, use the urlPatterns
attribute when other attributes are also used.
Classes annotated with @WebServlet
must extend the javax.servlet.http.HttpServlet
class. For example, the following code snippet defines a servlet with the URL pattern /report
:
import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; @WebServlet("/report") public class MoodServlet extends HttpServlet { ...
The web container initializes a servlet after loading and instantiating the servlet class and before delivering requests from clients. To customize this process to allow the servlet to read persistent configuration data, initialize resources, and perform any other one-time activities, you can either override the init
method of the Servlet
interface or specify the initParams
attribute of the @WebServlet
annotation. The initParams
attribute contains a @WebInitParam
annotation. If it cannot complete its initialization process, a servlet throws an UnavailableException
.
Use an initialization parameter to provide data needed by a particular servlet. By contrast, a context parameter provides data that is available to all components of a web application.
The service provided by a servlet is implemented in the service
method of a GenericServlet
, in the do
Method methods (where Method can take the value Get
, Delete
, Options
, Post
, Put
, or Trace
) of an HttpServlet
object, or in any other protocol-specific methods defined by a class that implements the Servlet
interface. The term service method is used for any method in a servlet class that provides a service to a client.
The general pattern for a service method is to extract information from the request, access external resources, and then populate the response, based on that information. For HTTP servlets, the correct procedure for populating the response is to do the following:
Retrieve an output stream from the response.
Fill in the response headers.
Write any body content to the output stream.
Response headers must always be set before the response has been committed. The web container will ignore any attempt to set or add headers after the response has been committed. The next two sections describe how to get information from requests and generate responses.
A request contains data passed between a client and the servlet. All requests implement the ServletRequest
interface. This interface defines methods for accessing the following information:
Parameters, which are typically used to convey information between clients and servlets
Object-valued attributes, which are typically used to pass information between the web container and a servlet or between collaborating servlets
Information about the protocol used to communicate the request and about the client and server involved in the request
Information relevant to localization
You can also retrieve an input stream from the request and manually parse the data. To read character data, use the BufferedReader
object returned by the request's getReader
method. To read binary data, use the ServletInputStream
returned by getInputStream
.
HTTP servlets are passed an HTTP request object, HttpServletRequest
, which contains the request URL, HTTP headers, query string, and so on. An HTTP request URL contains the following parts:
http://[host]:[port][request-path]?[query-string]
The request path is further composed of the following elements.
Context path: A concatenation of a forward slash (/
) with the context root of the servlet's web application.
Servlet path: The path section that corresponds to the component alias that activated this request. This path starts with a forward slash (/
).
Path info: The part of the request path that is not part of the context path or the servlet path.
You can use the getContextPath
, getServletPath
, and getPathInfo
methods of the HttpServletRequest
interface to access this information. Except for URL encoding differences between the request URI and the path parts, the request URI is always comprised of the context path plus the servlet path plus the path info.
Query strings are composed of a set of parameters and values. Individual parameters are retrieved from a request by using the getParameter
method. There are two ways to generate query strings.
A query string can explicitly appear in a web page.
A query string is appended to a URL when a form with a GET
HTTP method is submitted.
A response contains data passed between a server and the client. All responses implement the ServletResponse
interface. This interface defines methods that allow you to do the following.
Retrieve an output stream to use to send data to the client. To send character data, use the PrintWriter
returned by the response's getWriter
method. To send binary data in a Multipurpose Internet Mail Extensions (MIME) body response, use the ServletOutputStream
returned by getOutputStream
. To mix binary and text data, as in a multipart response, use a ServletOutputStream
and manage the character sections manually.
Indicate the content type (for example, text/html
) being returned by the response with the setContentType(String)
method. This method must be called before the response is committed. A registry of content type names is kept by the Internet Assigned Numbers Authority (IANA) at http://www.iana.org/assignments/media-types/
.
Indicate whether to buffer output with the setBufferSize(int)
method. By default, any content written to the output stream is immediately sent to the client. Buffering allows content to be written before anything is sent back to the client, thus providing the servlet with more time to set appropriate status codes and headers or forward to another web resource. The method must be called before any content is written or before the response is committed.
Set localization information, such as locale and character encoding. See Chapter 20, "Internationalizing and Localizing Web Applications" for details.
HTTP response objects, javax.servlet.http.HttpServletResponse
, have fields representing HTTP headers, such as the following.
Status codes, which are used to indicate the reason a request is not satisfied or that a request has been redirected.
Cookies, which are used to store application-specific information at the client. Sometimes, cookies are used to maintain an identifier for tracking a user's session (see Session Tracking).
A filter is an object that can transform the header and content (or both) of a request or response. Filters differ from web components in that filters usually do not themselves create a response. Instead, a filter provides functionality that can be "attached" to any kind of web resource. Consequently, a filter should not have any dependencies on a web resource for which it is acting as a filter; this way, it can be composed with more than one type of web resource.
The main tasks that a filter can perform are as follows.
Query the request and act accordingly.
Block the request-and-response pair from passing any further.
Modify the request headers and data. You do this by providing a customized version of the request.
Modify the response headers and data. You do this by providing a customized version of the response.
Interact with external resources.
Applications of filters include authentication, logging, image conversion, data compression, encryption, tokenizing streams, XML transformations, and so on.
You can configure a web resource to be filtered by a chain of zero, one, or more filters in a specific order. This chain is specified when the web application containing the component is deployed and is instantiated when a web container loads the component.
The filtering API is defined by the Filter
, FilterChain
, and FilterConfig
interfaces in the javax.servlet
package. You define a filter by implementing the Filter
interface.
Use the @WebFilter
annotation to define a filter in a web application. This annotation is specified on a class and contains metadata about the filter being declared. The annotated filter must specify at least one URL pattern. This is done by using the urlPatterns
or value
attribute on the annotation. All other attributes are optional, with default settings. Use the value
attribute when the only attribute on the annotation is the URL pattern; use the urlPatterns
attribute when other attributes are also used.
Classes annotated with the @WebFilter
annotation must implement the javax.servlet.Filter
interface.
To add configuration data to the filter, specify the initParams
attribute of the @WebFilter
annotation. The initParams
attribute contains a @WebInitParam
annotation. The following code snippet defines a filter, specifying an initialization parameter:
import javax.servlet.Filter; import javax.servlet.annotation.WebFilter; import javax.servlet.annotation.WebInitParam; @WebFilter(filterName = "TimeOfDayFilter", urlPatterns = {"/*"}, initParams = { @WebInitParam(name = "mood", value = "awake")}) public class TimeOfDayFilter implements Filter { ...
The most important method in the Filter
interface is doFilter
, which is passed request, response, and filter chain objects. This method can perform the following actions.
Examine the request headers.
Customize the request object if the filter wishes to modify request headers or data.
Customize the response object if the filter wishes to modify response headers or data.
Invoke the next entity in the filter chain. If the current filter is the last filter in the chain that ends with the target web component or static resource, the next entity is the resource at the end of the chain; otherwise, it is the next filter that was configured in the WAR. The filter invokes the next entity by calling the doFilter
method on the chain object, passing in the request and response it was called with or the wrapped versions it may have created. Alternatively, the filter can choose to block the request by not making the call to invoke the next entity. In the latter case, the filter is responsible for filling out the response.
Examine response headers after invoking the next filter in the chain.
Throw an exception to indicate an error in processing.
In addition to doFilter
, you must implement the init
and destroy
methods. The init
method is called by the container when the filter is instantiated. If you wish to pass initialization parameters to the filter, you retrieve them from the FilterConfig
object passed to init
.
There are many ways for a filter to modify a request or a response. For example, a filter can add an attribute to the request or can insert data in the response.
A filter that modifies a response must usually capture the response before it is returned to the client. To do this, you pass a stand-in stream to the servlet that generates the response. The stand-in stream prevents the servlet from closing the original response stream when it completes and allows the filter to modify the servlet's response.
To pass this stand-in stream to the servlet, the filter creates a response wrapper that overrides the getWriter
or getOutputStream
method to return this stand-in stream. The wrapper is passed to the doFilter
method of the filter chain. Wrapper methods default to calling through to the wrapped request or response object.
To override request methods, you wrap the request in an object that extends either ServletRequestWrapper
or HttpServletRequestWrapper
. To override response methods, you wrap the response in an object that extends either ServletResponseWrapper
or HttpServletResponseWrapper
.
A web container uses filter mappings to decide how to apply filters to web resources. A filter mapping matches a filter to a web component by name or to web resources by URL pattern. The filters are invoked in the order in which filter mappings appear in the filter mapping list of a WAR. You specify a filter mapping list for a WAR in its deployment descriptor by either using NetBeans IDE or coding the list by hand with XML.
If you want to log every request to a web application, you map the hit counter filter to the URL pattern /*
.
You can map a filter to one or more web resources, and you can map more than one filter to a web resource. This is illustrated in Figure 17-1, in which filter F1 is mapped to servlets S1, S2, and S3; filter F2 is mapped to servlet S2; and filter F3 is mapped to servlets S1 and S2.
Recall that a filter chain is one of the objects passed to the doFilter
method of a filter. This chain is formed indirectly by means of filter mappings. The order of the filters in the chain is the same as the order in which filter mappings appear in the web application deployment descriptor.
When a filter is mapped to servlet S1, the web container invokes the doFilter
method of F1. The doFilter
method of each filter in S1's filter chain is invoked by the preceding filter in the chain by means of the chain.doFilter
method. Because S1's filter chain contains filters F1 and F3, F1's call to chain.doFilter
invokes the doFilter
method of filter F3. When F3's doFilter
method completes, control returns to F1's doFilter
method.
Expand the application's project node in the Project tab.
Expand the Web Pages and WEB-INF nodes under the project node.
Double-click web.xml
.
Click Filters at the top of the editor window.
Expand the Servlet Filters node in the editor window.
Click Add Filter Element to map the filter to a web resource by name or by URL pattern.
In the Add Servlet Filter dialog box, enter the name of the filter in the Filter Name field.
Click Browse to locate the servlet class to which the filter applies.
You can include wildcard characters so that you can apply the filter to more than one servlet.
Click OK.
To constrain how the filter is applied to requests, follow these steps.
Expand the Filter Mappings node.
Select the filter from the list of filters.
Click Add.
In the Add Filter Mapping dialog box, select one of the following dispatcher types:
REQUEST: Only when the request comes directly from the client
ASYNC: Only when the asynchronous request comes from the client
FORWARD: Only when the request has been forwarded to a component (see Transferring Control to Another Web Component)
INCLUDE: Only when the request is being processed by a component that has been included (see Including Other Resources in the Response)
ERROR: Only when the request is being processed with the error page mechanism (see Handling Servlet Errors)
You can direct the filter to be applied to any combination of the preceding situations by selecting multiple dispatcher types. If no types are specified, the default option is REQUEST.
Web components can invoke other web resources both indirectly and directly. A web component indirectly invokes another web resource by embedding a URL that points to another web component in content returned to a client. While it is executing, a web component directly invokes another resource by either including the content of another resource or forwarding a request to another resource.
To invoke a resource available on the server that is running a web component, you must first obtain a RequestDispatcher
object by using the getRequestDispatcher("URL")
method. You can get a RequestDispatcher
object from either a request or the web context; however, the two methods have slightly different behavior. The method takes the path to the requested resource as an argument. A request can take a relative path (that is, one that does not begin with a /
), but the web context requires an absolute path. If the resource is not available or if the server has not implemented a RequestDispatcher
object for that type of resource, getRequestDispatcher
will return null. Your servlet should be prepared to deal with this condition.
It is often useful to include another web resource, such as banner content or copyright information, in the response returned from a web component. To include another resource, invoke the include
method of a RequestDispatcher
object:
include(request, response);
If the resource is static, the include
method enables programmatic server-side includes. If the resource is a web component, the effect of the method is to send the request to the included web component, execute the web component, and then include the result of the execution in the response from the containing servlet. An included web component has access to the request object but is limited in what it can do with the response object.
It can write to the body of the response and commit a response.
It cannot set headers or call any method, such as setCookie
, that affects the headers of the response.
In some applications, you might want to have one web component do preliminary processing of a request and have another component generate the response. For example, you might want to partially process a request and then transfer to another component, depending on the nature of the request.
To transfer control to another web component, you invoke the forward
method of a RequestDispatcher
. When a request is forwarded, the request URL is set to the path of the forwarded page. The original URI and its constituent parts are saved as the following request attributes:
javax.servlet.forward.request_uri javax.servlet.forward.context_path javax.servlet.forward.servlet_path javax.servlet.forward.path_info javax.servlet.forward.query_string
The forward
method should be used to give another resource responsibility for replying to the user. If you have already accessed a ServletOutputStream
or PrintWriter
object within the servlet, you cannot use this method; doing so throws an IllegalStateException
.
The context in which web components execute is an object that implements the ServletContext
interface. You retrieve the web context by using the getServletContext
method. The web context provides methods for accessing
Initialization parameters
Resources associated with the web context
Object-valued attributes
Logging capabilities
The counter's access methods are synchronized to prevent incompatible operations by servlets that are running concurrently. A filter retrieves the counter object by using the context's getAttribute
method. The incremented value of the counter is recorded in the log.
Many applications require that a series of requests from a client be associated with one another. For example, a web application can save the state of a user's shopping cart across requests. Web-based applications are responsible for maintaining such state, called a session, because HTTP is stateless. To support applications that need to maintain state, Java Servlet technology provides an API for managing sessions and allows several mechanisms for implementing sessions.
Sessions are represented by an HttpSession
object. You access a session by calling the getSession
method of a request object. This method returns the current session associated with this request; or, if the request does not have a session, this method creates one.
You can associate object-valued attributes with a session by name. Such attributes are accessible by any web component that belongs to the same web context and is handling a request that is part of the same session.
Recall that your application can notify web context and session listener objects of servlet lifecycle events (Handling Servlet Lifecycle Events). You can also notify objects of certain events related to their association with a session, such as the following.
When the object is added to or removed from a session. To receive this notification, your object must implement the javax.servlet.http.HttpSessionBindingListener
interface.
When the session to which the object is attached will be passivated or activated. A session will be passivated or activated when it is moved between virtual machines or saved to and restored from persistent storage. To receive this notification, your object must implement the javax.servlet.http.HttpSessionActivationListener
interface.
Because an HTTP client has no way to signal that it no longer needs a session, each session has an associated timeout so that its resources can be reclaimed. The timeout period can be accessed by using a session's getMaxInactiveInterval
and setMaxInactiveInterval
methods.
To ensure that an active session is not timed out, you should periodically access the session by using service methods because this resets the session's time-to-live counter.
When a particular client interaction is finished, you use the session's invalidate
method to invalidate a session on the server side and remove any session data.
To set the timeout period in the deployment descriptor using NetBeans IDE, follow these steps.
Open the project if you haven't already.
Expand the node of your project in the Projects tab.
Expand the Web Pages and WEB-INF nodes that are under the project node.
Double-click web.xml
.
Click General at the top of the editor.
In the Session Timeout field, enter an integer value.
The integer value represents the number of minutes of inactivity that must pass before the session times out.
To associate a session with a user, a web container can use several methods, all of which involve passing an identifier between the client and the server. The identifier can be maintained on the client as a cookie, or the web component can include the identifier in every URL that is returned to the client.
If your application uses session objects, you must ensure that session tracking is enabled by having the application rewrite URLs whenever the client turns off cookies. You do this by calling the response's encodeURL(URL)
method on all URLs returned by a servlet. This method includes the session ID in the URL only if cookies are disabled; otherwise, the method returns the URL unchanged.
The web container may determine that a servlet should be removed from service (for example, when a container wants to reclaim memory resources or when it is being shut down). In such a case, the container calls the destroy
method of the Servlet
interface. In this method, you release any resources the servlet is using and save any persistent state. The destroy
method releases the database object created in the init
method.
A servlet's service methods should all be complete when a servlet is removed. The server tries to ensure this by calling the destroy
method only after all service requests have returned or after a server-specific grace period, whichever comes first. If your servlet has operations that may run longer than the server's grace period, the operations could still be running when destroy
is called. You must make sure that any threads still handling client requests complete.
The remainder of this section explains how to do the following.
Keep track of how many threads are currently running the service
method.
Provide a clean shutdown by having the destroy
method notify long-running threads of the shutdown and wait for them to complete.
Have the long-running methods poll periodically to check for shutdown and, if necessary, stop working, clean up, and return.
To track service requests, include in your servlet class a field that counts the number of service methods that are running. The field should have synchronized access methods to increment, decrement, and return its value:
public class ShutdownExample extends HttpServlet { private int serviceCounter = 0; ... // Access methods for serviceCounter protected synchronized void enteringServiceMethod() { serviceCounter++; } protected synchronized void leavingServiceMethod() { serviceCounter--; } protected synchronized int numServices() { return serviceCounter; } }
The service
method should increment the service counter each time the method is entered and should decrement the counter each time the method returns. This is one of the few times that your HttpServlet
subclass should override the service
method. The new method should call super.service
to preserve the functionality of the original service
method:
protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException,IOException { enteringServiceMethod(); try { super.service(req, resp); } finally { leavingServiceMethod(); } }
To ensure a clean shutdown, your destroy
method should not release any shared resources until all the service requests have completed. One part of doing this is to check the service counter. Another part is to notify long-running methods that it is time to shut down. For this notification, another field is required. The field should have the usual access methods:
public class ShutdownExample extends HttpServlet { private boolean shuttingDown; ... //Access methods for shuttingDown protected synchronized void setShuttingDown(boolean flag) { shuttingDown = flag; } protected synchronized boolean isShuttingDown() { return shuttingDown; } }
Here is an example of the destroy
method using these fields to provide a clean shutdown:
public void destroy() { /* Check to see whether there are still service methods /* /* running, and if there are, tell them to stop. */ if (numServices()> 0) { setShuttingDown(true); } /* Wait for the service methods to stop. */ while (numServices()> 0) { try { Thread.sleep(interval); } catch (InterruptedException e) { } } }
The final step in providing a clean shutdown is to make any long-running methods behave politely. Methods that might run for a long time should check the value of the field that notifies them of shutdowns and should interrupt their work, if necessary:
public void doPost(...) { ... for(i = 0; ((i < lotsOfStuffToDo) && !isShuttingDown()); i++) { try { partOfLongRunningOperation(i); } catch (InterruptedException e) { ... } } }
Supporting file uploads is a very basic and common requirement for many web applications. In prior versions of the Servlet specification, implementing file upload required the use of external libraries or complex input processing. The Java Servlet specification now helps to provide a viable solution to the problem in a generic and portable way. Java Servlet technology now supports file upload out of the box, so any web container that implements the specification can parse multipart requests and make mime attachments available through the HttpServletRequest
object.
A new annotation, javax.servlet.annotation.MultipartConfig
, is used to indicate that the servlet on which it is declared expects requests to be made using the multipart/form-data
MIME type. Servlets that are annotated with @MultipartConfig
can retrieve the Part
components of a given multipart/form-data
request by calling the request.getPart(String name)
or request.getParts()
method.
The @MultipartConfig
annotation supports the following optional attributes.
location
: An absolute path to a directory on the file system. The location
attribute does not support a path relative to the application context. This location is used to store files temporarily while the parts are processed or when the size of the file exceeds the specified fileSizeThreshold
setting. The default location is ""
.
fileSizeThreshold
: The file size in bytes after which the file will be temporarily stored on disk. The default size is 0 bytes.
MaxFileSize
: The maximum size allowed for uploaded files, in bytes. If the size of any uploaded file is greater than this size, the web container will throw an exception (IllegalStateException
). The default size is unlimited.
maxRequestSize
: The maximum size allowed for a multipart/form-data
request, in bytes. The web container will throw an exception if the overall size of all uploaded files exceeds this threshold. The default size is unlimited.
For, example, the @MultipartConfig
annotation could be constructed as follows:
@MultipartConfig(location="/tmp", fileSizeThreshold=1024*1024, maxFileSize=1024*1024*5, maxRequestSize=1024*1024*5*5)
Instead of using the @MultipartConfig
annotation to hard-code these attributes in your file upload servlet, you could add the following as a child element of the servlet configuration element in the web.xml
file:
<multipart-config> <location>/tmp</location> <max-file-size>20848820</max-file-size> <max-request-size>418018841</max-request-size> <file-size-threshold>1048576</file-size-threshold> </multipart-config>
The Servlet specification supports two additional HttpServletRequest
methods:
Collection<Part> getParts()
Part getPart(String name)
The request.getParts()
method returns collections of all Part
objects. If you have more than one input of type file, multiple Part
objects are returned. Because Part
objects are named, the getPart(String name)
method can be used to access a particular Part
. Alternatively, the getParts()
method, which returns an Iterable<Part>
, can be used to get an Iterator
over all the Part
objects.
The javax.servlet.http.Part
interface is a simple one, providing methods that allow introspection of each Part
. The methods do the following:
Retrieve the name, size, and content-type of the Part
Query the headers submitted with a Part
Delete a Part
Write a Part
out to disk
For example, the Part
interface provides the write(String filename)
method to write the file with the specified name. The file can then be saved in the directory that is specified with the location
attribute of the @MultipartConfig
annotation or, in the case of the fileupload
example, in the location specified by the Destination field in the form.
Web containers in application servers normally use a server thread per client request. Under heavy load conditions, containers need a large amount of threads to serve all the client requests. Scalability limitations include running out of memory or exhausting the pool of container threads. To create scalable web applications, you must ensure that no threads associated with a request are sitting idle, so the container can use them to process new requests.
There are two common scenarios in which a thread associated with a request can be sitting idle.
The thread needs to wait for a resource to become available or process data before building the response. For example, an application may need to query a database or access data from a remote web service before generating the response.
The thread needs to wait for an event before generating the response. For example, an application may have to wait for a JMS message, new information from another client, or new data available in a queue before generating the response.
These scenarios represent blocking operations that limit the scalability of web applications. Asynchronous processing refers to assigning these blocking operations to a new thread and retuning the thread associated with the request immediately to the container.
Java EE provides asynchronous processing support for servlets and filters. If a servlet or a filter reaches a potentially blocking operation when processing a request, it can assign the operation to an asynchronous execution context and return the thread associated with the request immediately to the container without generating a response. The blocking operation completes in the asynchronous execution context in a different thread, which can generate a response or dispatch the request to another servlet.
To enable asynchronous processing on a servlet, set the parameter asyncSupported
to true
on the @WebServlet
annotation as follows:
@WebServlet(urlPatterns={"/asyncservlet"}, asyncSupported=true) public class AsyncServlet extends HttpServlet { ... }
The javax.servlet.AsyncContext
class provides the functionality that you need to perform asynchronous processing inside service methods. To obtain an instance of AsyncContext
, call the startAsync()
method on the request object of your service method; for example:
public void doGet(HttpServletRequest req, HttpServletResponse resp) { ... AsyncContext acontext = req.startAsync(); ... }
This call puts the request into asynchronous mode and ensures that the response is not committed after exiting the service method. You have to generate the response in the asynchronous context after the blocking operation completes or dispatch the request to another servlet.
Table 17-3 describes the basic functionality provided by the AsyncContext
class.
Table 17-3 Functionality Provided by the AsyncContext Class
| Method Signature | Description |
|---|---|
|
|
The container provides a different thread in which the blocking operation can be processed. You provide code for the blocking operation as a class that implements the |
|
|
Returns the request used to initialize this asynchronous context. In the example above, the request is the same as in the service method. You can use this method inside the asynchronous context to obtain parameters from the request. |
|
|
Returns the response used to initialize this asynchronous context. In the example above, the response is the same as in the service method. You can use this method inside the asynchronous context to write to the response with the results of the blocking operation. |
|
|
Completes the asynchronous operation and closes the response associated with this asynchronous context. You call this method after writing to the response object inside the asynchronous context. |
|
|
Dispatches the request and response objects to the given path. You use this method to have another servlet write to the response after the blocking operation completes. |
This section demonstrates how to use the functionality provided by the AsyncContext
class for the following use case:
A servlet receives a parameter from a GET request.
The servlet uses a resource, such as a database or a web service, to retrieve information based on the value of the parameter. The resource can be slow at times, so this may be a blocking operation.
The servlet generates a response using the result from the resource.
The following code shows a basic servlet that does not use asynchronous processing:
@WebServlet(urlPatterns={"/syncservlet"}) public class SyncServlet extends HttpServlet { private MyRemoteResource resource; @Override public void init(ServletConfig config) { resource = MyRemoteResource.create("config1=x,config2=y"); } @Override public void doGet(HttpServletRequest request, HttpServletResponse response) { response.setContentType("text/html;charset=UTF-8"); String param = request.getParameter("param"); String result = resource.process(param); /* ... print to the response ... */ } }
The following code shows the same servlet using asynchronous processing:
@WebServlet(urlPatterns={"/asyncservlet"}, asyncSupported=true) public class AsyncServlet extends HttpServlet { /* ... Same variables and init method as in SyncServlet ... */ @Override public void doGet(HttpServletRequest request, HttpServletResponse response) { response.setContentType("text/html;charset=UTF-8"); final AsyncContext acontext = request.startAsync(); acontext.start(new Runnable() { public void run() { String param = acontext.getRequest().getParameter("param"); String result = resource.process(param); HttpServletResponse response = acontext.getResponse(); /* ... print to the response ... */ acontext.complete(); } }
AsyncServlet
adds asyncSupported=true
to the @WebServlet
annotation. The rest of the differences are inside the service method.
request.startAsync()
causes the request to be processed asynchronously; the response is not sent to the client at the end of the service method.
acontext.start(new Runnable() {...})
gets a new thread from the container.
The code inside the run()
method of the inner class executes in the new thread. The inner class has access to the asynchronous context to read parameters from the request and write to the response. Calling the complete()
method of the asynchronous context commits the response and sends it to the client.
The service method of AsyncServlet
returns immediately, and the request is processed in the asynchronous context.
Web containers in application servers normally use a server thread per client request. To develop scalable web applications, you must ensure that threads associated with client requests are never sitting idle waiting for a blocking operation to complete. Asynchronous Processing provides a mechanism to execute application-specific blocking operations in a new thread, returning the thread associated with the request immediately to the container. Even if you use asynchronous processing for all the application-specific blocking operations inside your service methods, threads associated with client requests can be momentarily sitting idle because of input/output considerations.
For example, if a client is submitting a large HTTP POST request over a slow network connection, the server can read the request faster than the client can provide it. Using traditional I/O, the container thread associated with this request would be sometimes sitting idle waiting for the rest of the request.
Java EE provides nonblocking I/O support for servlets and filters when processing requests in asynchronous mode. The following steps summarize how to use nonblocking I/O to process requests and write responses inside service methods.
Put the request in asynchronous mode as described in Asynchronous Processing.
Obtain an input stream and/or an output stream from the request and response objects in the service method.
Assign a read listener to the input stream and/or a write listener to the output stream.
Process the request and the response inside the listener's callback methods.
Table 17-4 and Table 17-5 describe the methods available in the servlet input and output streams for nonblocking I/O support. Table 17-6 describes the interfaces for read listeners and write listeners.
Table 17-4 Nonblocking I/O Support in javax.servlet.ServletInputStream
| Method | Description |
|---|---|
|
|
Associates this input stream with a listener object that contains callback methods to read data asynchronously. You provide the listener object as an anonymous class or use another mechanism to pass the input stream to the read listener object. |
|
|
Returns true if data can be read without blocking. |
|
|
Returns true when all the data has been read. |
Table 17-5 Nonblocking I/O Support in javax.servlet.ServletOutputStream
| Method | Description |
|---|---|
|
|
Associates this output stream with a listener object that contains callback methods to write data asynchronously. You provide the write listener object as an anonymous class or use another mechanism to pass the output stream to the write listener object. |
|
|
Returns true if data can be written without blocking. |
Table 17-6 Listener Interfaces for Nonblocking I/O Support
| Interface | Methods | Description |
|---|---|---|
|
|
|
A |
|
|
|
A |
The code in this section shows how to read a large HTTP POST request inside a servlet by putting the request in asynchronous mode (as described in Asynchronous Processing) and using the nonblocking I/O functionality from Table 17-4 and Table 17-6.
@WebServlet(urlPatterns={"/asyncioservlet"}, asyncSupported=true) public class AsyncIOServlet extends HttpServlet { @Override public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException { final AsyncContext acontext = request.startAsync(); final ServletInputStream input = request.getInputStream(); input.setReadListener(new ReadListener() { byte buffer[] = new byte[4*1024]; StringBuilder sbuilder = new StringBuilder(); @Override public void onDataAvailable() { try { do { int length = input.read(buffer); sbuilder.append(new String(buffer, 0, length)); } while(input.isReady()); } catch (IOException ex) { ... } } @Override public void onAllDataRead() { try { acontext.getResponse().getWriter() .write("...the response..."); } catch (IOException ex) { ... } acontext.complete(); } @Override public void onError(Throwable t) { ... } }); } }
This example declares the web servlet with asynchronous support using the @WebServlet
annotation parameter asyncSupported=true
. The service method first puts the request in asynchronous mode by calling the startAsync()
method of the request object, which is required in order to use nonblocking I/O. Then, the service method obtains an input stream associated with the request and assigns a read listener defined as an inner class. The listener reads parts of the request as they become available and then writes some response to the client when it finishes reading the request.
In HTTP/1.1, clients can request to switch to a different protocol on the current connection by using the Upgrade
header field. If the server accepts the request to switch to the protocol indicated by the client, it generates an HTTP response with status 101 (switching protocols). After this exchange, the client and the server communicate using the new protocol.
For example, a client can make an HTTP request to switch to the XYZP protocol as follows:
GET /xyzpresource HTTP/1.1 Host: localhost:8080 Accept: text/html Upgrade: XYZP Connection: Upgrade OtherHeaderA: Value
The client can specify parameters for the new protocol using HTTP headers. The server can accept the request and generate a response as follows:
HTTP/1.1 101 Switching Protocols Upgrade: XYZP Connection: Upgrade OtherHeaderB: Value (XYZP data)
Java EE supports the HTTP protocol upgrade functionality in servlets, as described in Table 17-7.
Table 17-7 Protocol Upgrade Support
| Class or Interface | Method |
|---|---|
|
|
The upgrade method starts the protocol upgrade processing. This method instantiates a class that implements the You call the |
|
|
The |
|
|
The |
|
|
The |
|
|
The |
The following code demonstrates how to accept an HTTP protocol upgrade request from a client:
@WebServlet(urlPatterns={"/xyzpresource"}) public class XYZPUpgradeServlet extends HttpServlet { @Override public void doGet(HttpServletRequest request, HttpServletResponse response) { if ("XYZP".equals(request.getHeader("Upgrade"))) { /* Accept upgrade request */ response.setStatus(101); response.setHeader("Upgrade", "XYZP"); response.setHeader("Connection", "Upgrade"); response.setHeader("OtherHeaderB", "Value"); /* Delegate the connection to the upgrade handler */ XYZPUpgradeHandler = request.upgrade(XYZPUpgradeHandler.class); /* (the service method returns immedately) */ } else { /* ... write error response ... */ } } }
The XYZPUpgradeHandler
class handles the connection:
public class XYZPUpgradeHandler implements HttpUpgradeHandler { @Override public void init(WebConnection wc) { ServletInputStream input = wc.getInputStream(); ServletOutputStream output = wc.getOutputStream(); /* ... implement XYZP using these streams (protocol-specific) ... */ } @Override public void destroy() { ... } }
The class that implements HttpUpgradeHandler
uses the streams from the current connection to communicate with the client using the new protocol. See the Servlet 3.1 specification at http://jcp.org/en/jsr/detail?id=340
for details on HTTP protocol upgrade support.
The mood
example application, located in the tut-install/examples/web/servlet/mood/
directory, is a simple example that displays Duke's moods at different times during the day. The example shows how to develop a simple application by using the @WebServlet
, @WebFilter
, and @WebListener
annotations to create a servlet, a listener, and a filter.
The mood
example application is comprised of three components: mood.web.MoodServlet
, mood.web.TimeOfDayFilter
, and mood.web.SimpleServletListener
.
MoodServlet
, the presentation layer of the application, displays Duke's mood in a graphic, based on the time of day. The @WebServlet
annotation specifies the URL pattern:
@WebServlet("/report") public class MoodServlet extends HttpServlet { ...
TimeOfDayFilter
sets an initialization parameter indicating that Duke is awake:
@WebFilter(filterName = "TimeOfDayFilter", urlPatterns = {"/*"}, initParams = { @WebInitParam(name = "mood", value = "awake")}) public class TimeOfDayFilter implements Filter { ...
The filter calls the doFilter
method, which contains a switch
statement that sets Duke's mood based on the current time.
SimpleServletListener
logs changes in the servlet's lifecycle. The log entries appear in the server log.
You can use either NetBeans IDE or Maven to build, package, deploy, and run the mood
example.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
From the File menu, choose Open Project.
In the Open Project dialog box, navigate to:
tut-install/examples/web/servlet
Select the mood
folder.
Click Open Project.
In the Projects tab, right-click the mood
project and select Build.
In a web browser, enter the following URL:
http://localhost:8080/mood/report
The URL specifies the context root, followed by the URL pattern.
A web page appears with the title "Servlet MoodServlet at /mood", a text string describing Duke's mood, and an illustrative graphic.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
In a terminal window, go to:
tut-install/examples/web/servlet/mood/
Enter the following command to deploy the application:
mvn install
In a web browser, enter the following URL:
http://localhost:8080/mood/report
The URL specifies the context root, followed by the URL pattern.
A web page appears with the title "Servlet MoodServlet at /mood", a text string describing Duke's mood, and an illustrative graphic.
The fileupload
example, located in the tut-install/examples/web/servlet/fileupload/
directory, illustrates how to implement and use the file upload feature.
The Duke's Forest case study provides a more complex example that uploads an image file and stores its content in a database.
The fileupload
example application consists of a single servlet and an HTML form that makes a file upload request to the servlet.
This example includes a very simple HTML form with two fields, File and Destination. The input type, file
, enables a user to browse the local file system to select the file. When the file is selected, it is sent to the server as a part of a POST request. During this process, two mandatory restrictions are applied to the form with input type file
.
The enctype
attribute must be set to a value of multipart/form-data
.
Its method must be POST.
When the form is specified in this manner, the entire request is sent to the server in encoded form. The servlet then uses its own means to handle the request to process the incoming file data and extract a file from the stream. The destination is the path to the location where the file will be saved on your computer. Pressing the Upload button at the bottom of the form posts the data to the servlet, which saves the file in the specified destination.
The HTML form in index.html
is as follows:
<!DOCTYPE html> <html lang="en"> <head> <title>File Upload</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <form method="POST" action="upload" enctype="multipart/form-data" > File: <input type="file" name="file" id="file" /> <br/> Destination: <input type="text" value="/tmp" name="destination"/> </br> <input type="submit" value="Upload" name="upload" id="upload" /> </form> </body> </html>
A POST request method is used when the client needs to send data to the server as part of the request, such as when uploading a file or submitting a completed form. In contrast, a GET request method sends a URL and headers only to the server, whereas POST requests also include a message body. This allows arbitrary length data of any type to be sent to the server. A header field in the POST request usually indicates the message body's Internet media type.
When submitting a form, the browser streams the content in, combining all parts, with each part representing a field of a form. Parts are named after the input
elements and are separated from each other with string delimiters named boundary
.
This is what submitted data from the fileupload
form looks like, after selecting sample.txt
as the file that will be uploaded to the tmp
directory on the local file system:
POST /fileupload/upload HTTP/1.1 Host: localhost:8080 Content-Type: multipart/form-data; boundary=---------------------------263081694432439 Content-Length:<PHONE_NUMBER>94432439 Content-Disposition: form-data; name="file"; filename="sample.txt" Content-Type: text/plain Data from sample file -----------------------------263081694432439 Content-Disposition: form-data; name="destination" /tmp -----------------------------263081694432439 Content-Disposition: form-data; name="upload" Upload -----------------------------263081694432439--
The servlet FileUploadServlet.java
begins as follows:
@WebServlet(name = "FileUploadServlet", urlPatterns = {"/upload"}) @MultipartConfig public class FileUploadServlet extends HttpServlet { private final static Logger LOGGER = Logger.getLogger(FileUploadServlet.class.getCanonicalName());
The @WebServlet
annotation uses the urlPatterns
property to define servlet mappings.
The @MultipartConfig
annotation indicates that the servlet expects requests to be made using the multipart/form-data
MIME type.
The processRequest
method retrieves the destination and file part from the request, then calls the getFileName
method to retrieve the file name from the file part. The method then creates a FileOutputStream
and copies the file to the specified destination. The error-handling section of the method catches and handles some of the most common reasons why a file would not be found. The processRequest
and getFileName
methods look like this:
protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html;charset=UTF-8"); // Create path components to save the file final String path = request.getParameter("destination"); final Part filePart = request.getPart("file"); final String fileName = getFileName(filePart); OutputStream out = null; InputStream filecontent = null; final PrintWriter writer = response.getWriter(); try { out = new FileOutputStream(new File(path + File.separator + fileName)); filecontent = filePart.getInputStream(); int read = 0; final byte[] bytes = new byte[1024]; while ((read = filecontent.read(bytes)) != -1) { out.write(bytes, 0, read); } writer.println("New file " + fileName + " created at " + path); LOGGER.log(Level.INFO, "File{0}being uploaded to {1}", new Object[]{fileName, path}); } catch (FileNotFoundException fne) { writer.println("You either did not specify a file to upload or are " + "trying to upload a file to a protected or nonexistent " + "location."); writer.println("<br/> ERROR: " + fne.getMessage()); LOGGER.log(Level.SEVERE, "Problems during file upload. Error: {0}", new Object[]{fne.getMessage()}); } finally { if (out != null) { out.close(); } if (filecontent != null) { filecontent.close(); } if (writer != null) { writer.close(); } } } private String getFileName(final Part part) { final String partHeader = part.getHeader("content-disposition"); LOGGER.log(Level.INFO, "Part Header = {0}", partHeader); for (String content : part.getHeader("content-disposition").split(";")) { if (content.trim().startsWith("filename")) { return content.substring( content.indexOf('=') + 1).trim().replace("\"", ""); } } return null; }
You can use either NetBeans IDE or Maven to build, package, deploy, and run the fileupload
example.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
From the File menu, choose Open Project.
In the Open Project dialog box, navigate to:
tut-install/examples/web/servlet
Select the fileupload
folder.
Click Open Project.
In the Projects tab, right-click the fileupload
project and select Build.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
In a terminal window, go to:
tut-install/examples/web/servlet/fileupload/
Enter the following command to deploy the application:
mvn install
In a web browser, enter the following URL:
http://localhost:8080/fileupload/
On the File Upload page, click Choose File to display a file browser window.
Select a file to upload and click Open.
The name of the file you selected is displayed in the File field. If you do not select a file, an exception will be thrown.
In the Destination field, type a directory name.
The directory must have already been created and must also be writable. If you do not enter a directory name or if you enter the name of a nonexistent or protected directory, an exception will be thrown.
Click Upload to upload the file that you selected to the directory that you specified in the Destination field.
A message reports that the file was created in the directory that you specified.
Go to the directory that you specified in the Destination field and verify that the uploaded file is present.
The dukeetf
example application, located in the tut-install/examples/web/dukeetf/
directory, demonstrates how to use asynchronous processing in a servlet to provide data updates to web clients. The example resembles a service that provides periodic updates on the price and trading volume of an electronically traded fund (ETF).
The dukeetf
example application consists of a servlet, an enterprise bean, and an HTML page.
The servlet puts requests in asynchronous mode, stores them in a queue, and writes the responses when new data for price and trading volume becomes available.
The enterprise bean updates the price and volume information once every second.
The HTML page uses JavaScript code to make requests to the servlet for new data, parse the response from the servlet, and update the price and volume information without reloading the page.
The dukeetf
example application uses a programming model known as long polling. In the traditional HTTP request and response model, the user must make an explicit request (such as clicking a link or submitting a form) to get any new information from the server, and the page has to be reloaded. Long polling provides a mechanism for web applications to push updates to clients using HTTP without the user making an explicit request. The server handles connections asynchronously, and the client uses JavaScript to make new connections. In this model, clients make a new request immediately after receiving new data, and the server keeps the connection open until new data becomes available.
The DukeETFServlet
class uses asynchronous processing:
@WebServlet(urlPatterns={"/dukeetf"}, asyncSupported=true) public class DukeETFServlet extends HttpServlet { ... }
In the following code, the init
method initializes a queue to hold client requests and registers the servlet with the enterprise bean that provides the price and volume updates. The send
method gets called once per second by the PriceVolumeBean
to send updates and close the connection:
@Override public void init(ServletConfig config) { /* Queue for requests */ requestQueue = new ConcurrentLinkedQueue<>(); /* Register with the enterprise bean that provides price/volume updates */ pvbean.registerServlet(this); } /* PriceVolumeBean calls this method every second to send updates */ public void send(double price, int volume) { /* Send update to all connected clients */ for (AsyncContext acontext : requestQueue) { try { String msg = String.format("%.2f / %d", price, volume); PrintWriter writer = acontext.getResponse().getWriter(); writer.write(msg); logger.log(Level.INFO, "Sent: {0}", msg); /* Close the connection * The client (JavaScript) makes a new one instantly */ acontext.complete(); } catch (IOException ex) { logger.log(Level.INFO, ex.toString()); } } }
The service method puts client requests in asynchronous mode and adds a listener to each request. The listener is implemented as an anonymous class that removes the request from the queue when the servlet finishes writing a response or when there is an error. Finally, the service method adds the request to the request queue created in the init
method. The service method is the following:
@Override public void doGet(HttpServletRequest request, HttpServletResponse response) { response.setContentType("text/html"); /* Put request in async mode */ final AsyncContext acontext = request.startAsync(); /* Remove from the queue when done */ acontext.addListener(new AsyncListener() { public void onComplete(AsyncEvent ae) throws IOException { requestQueue.remove(acontext); } public void onTimeout(AsyncEvent ae) throws IOException { requestQueue.remove(acontext); } public void onError(AsyncEvent ae) throws IOException { requestQueue.remove(acontext); } public void onStartAsync(AsyncEvent ae) throws IOException {} }); /* Add to the queue */ requestQueue.add(acontext); }
The PriceVolumeBean
class is an enterprise bean that uses the timer service from the container to update the price and volume information and call the servlet's send
method once every second:
@Startup @Singleton public class PriceVolumeBean { /* Use the container's timer service */ @Resource TimerService tservice; private DukeETFServlet servlet; ... @PostConstruct public void init() { /* Initialize the EJB and create a timer */ random = new Random(); servlet = null; tservice.createIntervalTimer(1000, 1000, new TimerConfig()); } public void registerServlet(DukeETFServlet servlet) { /* Associate a servlet to send updates to */ this.servlet = servlet; } @Timeout public void timeout() { /* Adjust price and volume and send updates */ price += 1.0*(random.nextInt(100)-50)/100.0; volume += random.nextInt(5000) - 2500; if (servlet != null) servlet.send(price, volume); } }
See Using the Timer Service in Chapter 34, "Running the Enterprise Bean Examples" for more information on the timer service.
The HTML page consists of a table and some JavaScript code. The table contains two fields referenced from JavaScript code:
<html xmlns="http://www.w3.org/1999/xhtml"> <head>...</head> <body onload="makeAjaxRequest();"> ... <table> ... <td id="price">--.--</td> ... <td id="volume">--</td> ... </table> </body> </html>
The JavaScript code uses the XMLHttpRequest
API, which provides functionality for transferring data between a client and a server. The script makes an asynchronous request to the servlet and designates a callback method. When the server provides a response, the callback method updates the fields in the table and makes a new request. The JavaScript code is the following:
var ajaxRequest; function updatePage() { if (ajaxRequest.readyState === 4) { var arraypv = ajaxRequest.responseText.split("/"); document.getElementById("price").innerHTML = arraypv[0]; document.getElementById("volume").innerHTML = arraypv[1]; makeAjaxRequest(); } } function makeAjaxRequest() { ajaxRequest = new XMLHttpRequest(); ajaxRequest.onreadystatechange = updatePage; ajaxRequest.open("GET", "http://localhost:8080/dukeetf/dukeetf", true); ajaxRequest.send(null); }
The XMLHttpRequest
API is supported by most modern browsers, and it is widely used in Ajax web client development (Asynchronous JavaScript and XML).
See The dukeetf2 Example Application in Chapter 18, "Java API for WebSocket" for an equivalent version of this example implemented using a WebSocket endpoint.
This section describes how to run the dukeetf
example application using NetBeans IDE and from the command line.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
From the File menu, choose Open Project.
In the Open Project dialog box, navigate to:
tut-install/examples/web/servlet
Select the dukeetf
folder.
Click Open Project.
In the Projects tab, right-click the dukeetf
project and select Run.
This command builds and packages the application into a WAR file (dukeetf.war
) located in the target
directory, deploys it to the server, and launches a web browser window with the following URL:
http://localhost:8080/dukeetf/
Open the same URL in a different web browser to see how both pages get price and volume updates simultaneously.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
In a terminal window, go to:
tut-install/examples/web/servlet/dukeetf/
Enter the following command to deploy the application:
mvn install
Open a web browser window and type the following address:
http://localhost:8080/dukeetf/
Open the same URL in a different web browser to see how both pages get price and volume updates simultaneously.
For more information on Java Servlet technology, see the Java Servlet 3.1 specification at http://jcp.org/en/jsr/detail?id=340
.


The requests matching the following pattern is served by the other servers defined
<%= JSON.stringify(config.proxyUrls, null, ' ') %>


Browser back button
Link to previous page to test how polyfill works with browser back button
Types
Maxlength
Similar CSS classes
Initial value
Change value after page load
Change placeholder after page load
Add placeholder after page load
Change input type (does not work in IE < 9)
Remove placeholder attribute
Form
Input with form attribute
Disabled inputs
Enabled after page load
Disabled after page load
Labels
A Link with "javascript:void(0)"
A Link with "javascript:void(0)" as href


| Home | Getting Started | Usability Test Script | Report |
CS 510 Spoken Language Interfaces
Assignment 4: GeneraList
| Michael Lane |<EMAIL_ADDRESS>|
GeneraList lets you use Amazon's Alexa to create and use lists that hold any type of data. Ask GeneraList to store grocery items as you think of them during the week and then access those items when you're on the go at the supermarket. Or give generalist a list of instructions that Alexa can read off to you later as you ask her to. Have a recipe that you love? Let GeneraList read the instructions to you as you're cooking.
main.py - The AWS lambda handler for GeneraList Alexa events.
Interaction Model - The intent schema used for GeneraList. This includes the intent schema, custom slot types, and sample utterances.
| Home | Getting Started | Usability Test Script | Report |


| Fetch endpoint url | |
| Time to Trigger | |
| Chrome flags setup correctly |
| Was sheet peeked | |
| Was button shown | |
| Was sheet opened | |
| Was sheet closed | |
| Any suggestion taken | |
| Any suggestion downloaded |
| Url | |
| Snippet | |
| Publisher name |
| Peek confidence | |
| Page scroll percentage | |
| Minimum seconds on page | |
| Maximum number of peeks |


Gourd Light Artistry Pricing, Shipping, and Returns
Pricing
Thank you for shopping at Gourd Light Artistry. My prices are based upon the complexity, scale, and time devoted to creating each lamp, from the initial cleaning of the dried gourd to the finishing of each piece. At least fifty hours are spent in the multi-layered process. In this context, the value of the lamps far exceeds the price paid. Please be assured that I also take into consideration fair market value for similar work.
A percentage of all proceeds will be dononated to the ASPCA.
Shipping
Domestic Shipping on your order is free, by Priority Mail, and I use USPS confirmation and tracking on the shipment.
International Shipping charges: If you are purchasing my work from outside the U.S. please email me at<EMAIL_ADDRESS>prior to completing your order about shipping charges.
Returns
You have 30 calendar days to return the piece from the date you received it. I am a tiny business and will do everything I can to make sure you are fully satisfied with your GourdLight Artistry lamp. I am eager to get your reactions!
Please feel free to contact me with questions and comments on the Gourd Light Artistry Facebook page.
To purchase a lamp email me at gourdlightartistry@gmail.com


0% Progress. Fill in the sums and click Solve!
Instructions
Voltorb Freedom! is easy to use. To start:
- Set the Voltorb counts and coin sums given to you by the puzzle.
- Press Solve!
While the solver is running...
-
Inspect the chances that a given
cell contains either a coin or Voltorb by clicking on the "Chance"
tab. Every time the solver finds a new feasible solution, it will
update the cell probabilities.
-
View feasible answers to the puzzle in the "Answers"
tab. Maybe you see a pattern the solver doesn't and can make a choice
before it finishes.
-
If you figure out some cells while the solver is running, you can
hit "Stop!", flip the cells in the "Input" tab and start it up again.
This will narrow down the feasible answers the solver needs to look
for and give you more specific suggestions when it finishes.
-
If the solver figures out some cells while it is running, they will
be updated in the "Input" tab. No need to wait until the end to
keep playing!
-
See how close the solver is to finishing in the progress bar below
the puzzle grid.
After the solver finishes
-
Voltorb Flip! will make suggestions for your next move in the
"Suggestions and Messages" box. It's up to you to decide which
cell you'll flip next.
-
Flip one or more cells in Pokemon and then update the contents in
the "Input" tab of Voltorb Freedom! Press "Solve!" to run the solver
again and get updated suggestions for cells to flip.
-
Voltorb Freedom can run with known Voltorbs (e.g. if you're running on
an emulator and are using the calculator to speed up your games).
For more help or to make suggestions, submit a new "issue" on
github.
What is Voltorb Freedom?
Voltorb Freedom is a solver for Voltorb Flip, a Minesweeper-like minigame
in Pokemon SoulSilver and HeartGold. Voltorb Flip is a game of chance:
for every puzzle, there ~1 Quadrillion (1×1015)
possible answers, of which up to Billions or Trillions may be feasible (they
satisfy the puzzle's Voltorb counts and Coin sums). Of those, only one
is the actual answer to the puzzle in the minigame.
Other Voltorb Flip calculators use basic logic to suggest your next move.
What sets Voltorb Freedom apart is that it finds every feasible answer to
a given puzzle and gives you the freedom to decide what to do with that
information. Would you rather flip the highest-probability cell or
choose the one with the greater reward or the one with the lowest chance of
having a Voltorb? Other calculators decide for you. Voltorb Freedom lets
you choose.
© 2018
Austin Milt.
The Voltorb Freedom! solver is the intellectual property of Austin Milt.
Voltorb Flip, including any images from the Pokemon games, are property of
Nintendo.


Builder API¶
Todo
Expand this.
-
class
sphinx.builders.
Builder
[source]¶ This is the base class for all builders.
These attributes should be set on builder classes:
-
name
= ‘’¶ The builder’s name, for the -b command line option.
-
format
= ‘’¶ The builder’s output format, or ‘’ if no document output is produced.
-
supported_image_types
= []¶ The list of MIME types of image formats supported by the builder. Image files are searched in the order in which they appear here.
These methods are predefined and will be called from the application:
-
get_relative_uri
(from_, to, typ=None)[source]¶ Return a relative URI between two source filenames.
May raise environment.NoUri if there’s no way to return a sensible URI.
-
build
(docnames, summary=None, method=’update’)[source]¶ Main build method.
First updates the environment, and then calls
write()
.
These methods can be overridden in concrete builder classes:
-
init
()[source]¶ Load necessary templates and perform initialization. The default implementation does nothing.
-
get_outdated_docs
()[source]¶ Return an iterable of output files that are outdated, or a string describing what an update build will build.
If the builder does not output individual files corresponding to source files, return a string here. If it does, return an iterable of those files that need to be written.
-
get_target_uri
(docname, typ=None)[source]¶ Return the target URI for a document name.
typ can be used to qualify the link characteristic for individual builders.
-
prepare_writing
(docnames)[source]¶ A place where you can add logic before
write_doc()
is run
-


Properties
To change the properties of this control during design time, invoke your development environment’s properties dialog for this control. You will be presented with three property pages for the control. The General tab is where you will select how help will be used for this control. The Colors tab will let you select colors to be used for this control. The fonts tab will let you select what font will be used for text in this control.
Here’s some help on the properties of this control:


File
Address
Remove Names
Delete Customer
Close
Close All
Backup...
Log Off
Edit
Undo
Redo
Cut
Copy
Paste
Clear
Select All
Reports
Kerala
Out of Kerala
Foreign
Modify Report
Options
Window
Arrange All
Hide
Cycle
Help
AMS Help
About AMS
Please Wait...
User Name:
Password :
Invalid Username or Password!
Address Details
-
□
✖
Customer Code :
Display Customer by Code :
Customer Name :
Group :
11
12
13
11 - Kerala, 12 - Out of Kerala, 13 - Foreign
Subscription Type :
L
F
H
E
P
Life/Free/Half/Exchange/Paid
### REMOVED ###
Address
Subscription
Previous Address
Address1 :
Address2 :
Address3 :
Taluk :
City :
District :
Pin :
State :
Country :
Contact No :
Press Modify to add subscription to this customer :
Address1 :
Address2 :
Address3 :
Taluk :
City :
District :
Pin :
State :
Country :
Invalid UserInput!
Remove Names
-
□
✖
Subscription Below Date :
Paid
Half
Removed
Modify Subscription
-
□
✖
Amount :
Subscription Period :
To
Instrument :
Cash
Cheque
Money Order
Demand Draft
Others
Instrument No :
Instrument Date :
Instrument Details :
Other Details :
Search Subscribers
-
□
✖
Modify Report
-
□
✖
Label Height :
Label Width :
Left Margin :
Top Margin :
Font Size :
Display Subscription


| DOSE: |
62.5 mg |
insufflated |
DPT |
(powder / crystals) |
Let me start with this.
I will not say where or how I got it, but I got 250mg of DPT, cost me $20. the first time I tried it, I took about 62.5mg from my 1/4 gram. I snorted it with a rolled dollar bill at a friends house, my friend who had just as much as I did was there with me, also trying it for the first time. We were waiting for our friends to get back from the bar. We do our 62.5mg in 2 lines and snorted a couple drops of water to knock it back. Before I get to the psychoactive effects, I'll let you know what the annoyances are.
First, it really didn't sting that much at all at first. Then it started tickling up in our sinuses, very much a different sensation than with any other powders. It tickled and kind stung at the same time and when the drips kicked in, it put a tolerable but unpleasant chemical taste in the back of our throats like dirty aspirin or something. then after a few minutes of drippage, our throats felt like they had been scratched raw on the inside, like we were getting a sore throat from a cold or something, but it definitely felt chemical related as opposed to the natural sore throat feeling. Then our nasal passages and throat slowly became numb and the annoyances subsided. The setting was good lighting throughout the place, background music, and a relatively clean place.
We felt stimulating effects within 5 minutes, colors and textures took on a sharp and almost static look at 10 minutes. Tracers, peripheral hallucinations/movement, empathogenic body high/almost weightlessness and patterns emerge from the carpets and walls at 15 minutes.  It reminded us of acid with how we kept smiling and giggling, but the visuals weren't quite as intense, and the mind expansion wasn't quite the same at all. It was there but very different/unique.
We put on SOAD's first album, one of my favorite tripping albums. As we lay upon the floor staring at the ceiling fan pointing different aspects of the trip out, the light bulb in the fan was very iridescent/colorful, and the colors were moving around in a random order. It reminded me of a crystal ball or something. The music was awesome. I had this trip where I was listening to the music and watching my friend move around in his psychedelic ways and dance, and it was like I could see the minds of the band members in the music.
I felt like I knew the origin in their souls of the music they oscillated. I felt I knew that Serj Tankian and his buddies most likely just took a lot of acid or whatever else they do and express their insanity in the music. It was depressing in a way, it was like their music was the language of the insanity they feed of off, like when he sang those weird ass lyrics, he was trying to get across some hidden meaning of life that he just couldn't verbalize, but he was trying and when I was watching my friend do his weird dances around the living room, going with the music, I felt that he felt the same thing I did about the hidden meaning in the music and I felt he was trying to tell me that he felt that way by doing his trippy physical expressions.  Colors were waving through surfaces as I turned my head or when I moved my eyes.
I also had this internal fluttering that I couldn't quite explain, like if I took too much more for my first time it would have looked like I was convulsing. It wasn't annoying though, it was just peculiar. the rest of the trip was pretty much mellow, intense conversations about past drug habits and experiences, conversations about trip music and whatnot, and then people started showing up right as we were starting to come down. The comedown was nice and gentle, we tapered off over the next 4 hours and even considering I had to get up for classes in the morning with only 4 1/2 hours of sleep, I had no unpleasant hangover or anything. I was actually in a nice mood all day. I can't stress enough, this chemical was surprisingly powerful.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Making vaccine information accessible to all.
TrackMyVaccine is a volunteer-led initiative of creating and managing an open database of the COVID-19 vaccines in Nepal. This citizen campaign tracks the management and distribution of COVID-19 vaccines in the country from multiple reliable sources and informs citizens of their status through an easy-to-navigate comprehensive online dashboard.
In early March 2021, Nepal became one of the first Asian countries to receive COVID-19 vaccines through COVAX, after being one of the first countries in the world to roll-out COVID-19 vaccination back in January 2021. It was believed that this support would accelerate the vaccination efforts of the country. Two months down the line, there is dismay among the general public as the 1.3million senior citizens await their second jab of Covishield vaccine. This has been further fueled by the media stories showing vaccines, which are already in limited stocks, are being accessed by those in power using personal channels. To a large extent, the general public relies on media posts to keep themselves updated about the vaccine landscape (at least on the management and implementation side). Despite significant demand, the government has not made COVID-19 vaccines management data public. As more news on vaccines aid pops in, transparency and accuracy of data on real time vaccine management becomes all the more important. After all, lack of transparency, or worse, [misinformation](https://twitter.com/TrackMyVac/status/1405735000931110919) will serve only to erode public trust in government and related stakeholders, which is not ideal.
TrackMyVaccine campaign takes the COVID-19 vaccine information into the public domain. This will not only help an individual to stay informed on the management, but support the Government and relevant agencies in efficient and equitable distribution.


--- layout: default --- {% if page.url == "/" %} {% assign notification_content = content | strip_html | strip %} {% if notification_content != "" %}
{% endif %} {% endif %}TRUSTED BY THESE AGENCIES
Benefits
Use OpenDoc to manage and edit your documents online. Our documents are indexed for search and mobile responsive by design, so you can spend more time on your content.


{{> systems/dh/templates/actors/actor-main.html}}
{{> systems/dh/templates/actors/actor-skills.html}}
{{> systems/dh/templates/actors/actor-talents.html}}
{{> systems/dh/templates/actors/actor-combat.html}}
{{> systems/dh/templates/actors/actor-magic.html}}
{{> systems/dh/templates/actors/actor-religion.html}}
{{> systems/dh/templates/actors/actor-inventory.html}}
{{> systems/dh/templates/actors/actor-notes.html}}


Abstraction is "the process of identifying common patterns that have systematic variations; an abstraction represents the common pattern and provides a means for specifying which variation to use" (Richard Gabriel).
Instead of making an object just suitable for the programmers themselves, what abstraction is trying to achieve is actually the opposite. Abstraction strives to make the object suitable for the domain in general. Programmers are able to use abstraction to construct a more generic solution that in turn solves more problems that have the same common pattern. This increases the re-usability of the components.
There are two aspects of encapsulation – packaging and information hiding.
Packaging: Related data or variable can be packaged in a self-contained unit. This can be done by using Classes to package low level data. As programmers, we need to be able to store respectively data in their related object or entity.
Information hiding: Multiple Object-Oriented languages enable programmers to hide information/data from the client and grant access only through the methods provided. In our case, Java, does it through the private and public access modifiers. A field or a method that is declared as private can only be accessed within the class itself, and cannot be accessed from outside the class. While, a public field or method can be accessed and even modified from outside of the class. By utilizing such mechanism, it maintains the abstraction barrier.
This might be able to better shed light on the accessibility of the modifiers:
| Class | Package | Subclass (same pkg) | Subclass (diff pkg) | World | |
|---|---|---|---|---|---|
| public | + | + | + | + | + |
| protected | + | + | + | + | |
| no modifier | + | + | + | ||
| private | + |
+ : accessible blank : not accessible
Let's see how the two aspect of encapsulation work to define a Student class in Java:
/**
* A Student object encapsulates their name.
*/
class Student {
private String name; // the name of the student
/**
* Return the name of the student.
*/
public double getName() {
return this.name;
}
/**
* Change the student’s name to a new name(newName)
*/
public void setName(String newName) {
this.name = newName;
}
}
The variable name is declared as a private field inside the class Student. As such, they can only be accessed and modified with the class that it was encapsulated within (inside the abstraction barrier), such as in the methods getName and setName.
| Abstraction | Encapsulation | |
|---|---|---|
| Purpose | To show relevant data and hide unwanted data | To hide the internal workings and data from the outside world |
| Implementation | Using abstract class and interface | Wrap the data and code into a single unit using class and protect data using access modifiers (Public, Protected and Private) |


UIGestureRecognizer
-
Equivalent to implementing UIGestureRecognizerDelegate’s gestureRecognizerShouldBegin(:) method
Declaration
Swift
public func shouldBegin(handler: @escaping () -> Bool) -> Self
Parameters
handler
The closure that will be called in place of its equivalent delegate method
Return Value
itself so you can daisy chain the other delegate calls
-
Equivalent to implementing UIGestureRecognizerDelegate’s gestureRecognizer(:shouldRecognizeSimultaneouslyWith:) method
Declaration
Swift
public func shouldRecognizeSimultaneouslyWith(handler: @escaping (_ otherGestureRecognizer: UIGestureRecognizer) -> Bool) -> Self
Parameters
handler
The closure that will be called in place of its equivalent delegate method
Return Value
itself so you can daisy chain the other delegate calls
-
Equivalent to implementing UIGestureRecognizerDelegate’s gestureRecognizer(:shouldRequireFailureOf:) method
Declaration
Swift
public func shouldRequireFailureOf(handler: @escaping (_ otherGestureRecognizer: UIGestureRecognizer) -> Bool) -> Self
Parameters
handler
The closure that will be called in place of its equivalent delegate method
Return Value
itself so you can daisy chain the other delegate calls
-
Equivalent to implementing UIGestureRecognizerDelegate’s gestureRecognizer(:shouldBeRequiredToFailBy:) method
Declaration
Swift
public func shouldBeRequiredToFailBy(handler: @escaping (_ otherGestureRecognizer: UIGestureRecognizer) -> Bool) -> Self
Parameters
handler
The closure that will be called in place of its equivalent delegate method
Return Value
itself so you can daisy chain the other delegate calls
-
Equivalent to implementing UIGestureRecognizerDelegate’s gestureRecognizer(:shouldReceive:) method
Declaration
Swift
public func shouldReceiveTouch(handler: @escaping (_ touch: UITouch) -> Bool) -> Self
Parameters
handler
The closure that will be called in place of its equivalent delegate method
Return Value
itself so you can daisy chain the other delegate calls
-
Equivalent to implementing UIGestureRecognizerDelegate’s gestureRecognizer(:shouldReceive:) method
Declaration
Swift
public func shouldReceivePress(handler: @escaping (_ press: UIPress) -> Bool) -> Self
Parameters
handler
The closure that will be called in place of its equivalent delegate method
Return Value
itself so you can daisy chain the other delegate calls
-
Clears any delegate closures that were assigned to this
UIGestureRecognizer
. This cleans up memory as well as sets the delegate property to nil. This is typically only used for explicit cleanup. You are not required to call this method.Declaration
Swift
@objc public func clearClosureDelegates()


|
|
| All911Edges (const int numVertices, const int maxEdges) |
| |
|
virtual void | setupEdges () override |
| | Setup the internal structure of the class (allocate memories and initialize them).
|
| |
| virtual void | createEdge (const BGSIZE iEdg, int srcVertex, int destVertex, BGFLOAT *sumPoint, const BGFLOAT deltaT, edgeType type) override |
| |
| virtual void | advanceEdges (IAllVertices *vertices, EdgeIndexMap *edgeIndexMap) |
| |
| void | advance911Edge (const BGSIZE iEdg, All911Vertices *vertices) |
| |
|
virtual void | advanceEdge (const BGSIZE iEdg, IAllVertices *vertices) override |
| | unused virtual function placeholder
|
| |
|
| AllEdges (const int numVertices, const int maxEdges) |
| |
| virtual void | loadParameters () |
| |
| virtual void | printParameters () const |
| |
| virtual void | addEdge (BGSIZE &iEdg, edgeType type, const int srcVertex, const int destVertex, BGFLOAT *sumPoint, const BGFLOAT deltaT) |
| |
|
virtual EdgeIndexMap * | createEdgeIndexMap () |
| | Create a edge index map.
|
| |
| template<class Archive > |
| void | save (Archive &archive) const |
| |
| template<class Archive > |
| void | load (Archive &archive) |
| |
| virtual void | eraseEdge (const int neuronIndex, const BGSIZE iEdg) |
| |
|
|
int * | sourceVertexIndex_ |
| | The location of the edge.
|
| |
|
int * | destVertexIndex_ |
| | The coordinates of the summation point.
|
| |
|
BGFLOAT * | W_ |
| | The weight (scaling factor, strength, maximal amplitude) of the edge.
|
| |
|
BGFLOAT ** | summationPoint_ |
| | This edge's summation point's address.
|
| |
|
edgeType * | type_ |
| | Synapse type.
|
| |
|
bool * | inUse_ |
| | The boolean value indicating the entry in the array is in use.
|
| |
| BGSIZE * | edgeCounts_ |
| |
|
BGSIZE | totalEdgeCount_ |
| | The total number of active edges.
|
| |
|
BGSIZE | maxEdgesPerVertex_ |
| | The maximum number of edges for each vertex.
|
| |
| int | countVertices_ |
| |
| virtual void | setupEdges (const int numVertices, const int maxEdges) |
| |
| virtual void | readEdge (istream &input, const BGSIZE iEdg) |
| |
| virtual void | writeEdge (ostream &output, const BGSIZE iEdg) const |
| |
| edgeType | edgeOrdinalToType (const int typeOrdinal) |
| |
|
log4cplus::Logger | fileLogger_ |
| | Loggers used to print to using log4cplus logging macros, prints to Results/Debug/logging.txt.
|
| |
|
log4cplus::Logger | edgeLogger_ |
| |
Definition at line 30 of file All911Edges.h.
◆ advance911Edge()
| void All911Edges::advance911Edge |
( |
const BGSIZE |
iEdg, |
|
|
All911Vertices * |
vertices |
|
) |
| |
Advance one specific Edge.
- Parameters
-
| iEdg | Index of the Edge to connect to. |
| vertices | The Neuron list to search from. |
Advance one specific edge.
- Parameters
-
| iEdg | Index of the edge to connect to. |
| vertices | The vertex list to search from. |
Definition at line 87 of file All911Edges.cpp.
◆ advanceEdges()
Advance all the edges in the simulation.
- Parameters
-
| vertices | The vertex list to search from. |
| edgeIndexMap | Pointer to EdgeIndexMap structure. |
Reimplemented from AllEdges.
Definition at line 72 of file All911Edges.cpp.
◆ Create()
| static AllEdges* All911Edges::Create |
( |
| ) |
|
|
inlinestatic |
Creates an instance of the class.
- Returns
- Reference to the instance of the class.
Definition at line 41 of file All911Edges.h.
◆ createEdge()
| void All911Edges::createEdge |
( |
const BGSIZE |
iEdg, |
|
|
int |
srcVertex, |
|
|
int |
destVertex, |
|
|
BGFLOAT * |
sumPoint, |
|
|
const BGFLOAT |
deltaT, |
|
|
edgeType |
type |
|
) |
| |
|
overridevirtual |
Create a Edge and connect it to the model.
- Parameters
-
| iEdg | Index of the edge to set. |
| srcVertex | Coordinates of the source Neuron. |
| destVertex | Coordinates of the destination Neuron. |
| sumPoint | Summation point address. |
| deltaT | Inner simulation step duration. |
| type | Type of the Edge to create. |
Implements AllEdges.
Definition at line 56 of file All911Edges.cpp.
The documentation for this class was generated from the following files:


|
PWG Maui Meeting
Details |
|
uPnP : January 22 & 23
Plenary & IPP : January 24
IPP : January 25
IPP Fax : January 26
Meeting Location:
Sheraton Maui Resort
2605 Kaanapali Parkway
Lahaina, Hawaii 96761phone: +1<PHONE_NUMBER>
fax: +1<PHONE_NUMBER> |
|
The hotel rate is $225 per night.
- Ask for the PWG or IEEE-ISTO rate at this hotel.
- Deadline for reservations is January 4, 2000. A one
night deposit is required when making the reservation.
- All attendees are responsible for making their own
hotel reservations.
- There will be a meeting charge in the range of $35; participants are responsible for
their own lunch.
Register at https://www.ieee-isto.org/pwg/registration.html


{{/* Based off the solution found at https://discourse.gohugo.io/t/implementing-breadcrumb-navigation-in-hugo/1048/9 */}} {{ $url := replace .Permalink ( printf "%s" .Site.BaseURL ) "" }} {{ $.Scratch.Add "path" .Site.BaseURL }}


@******************************************************************************* * Licensed to the Apache Software Foundation (ASF) under one or more * * contributor license agreements. See the NOTICE file distributed with * * this work for additional information regarding copyright ownership. * * The ASF licenses this file to You under the Apache License, Version 2.0 * * (the "License"); you may not use this file except in compliance with * * the License. You may obtain a copy of the License at * * * * http://www.apache.org/licenses/LICENSE-2.0 * * * * Unless required by applicable law or agreed to in writing, software * * distributed under the License is distributed on an "AS IS" BASIS, * * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * * See the License for the specific language governing permissions and * * limitations under the License. * *******************************************************************************@ @(user: metadata.User) @import helper._ @main("User Profile") {
@user.getId()
@user.getUserName()
@user.getFirstName() @user.getLastName()
@user.getMiddleInitial
@user.getAffiliation
@user.getTitle()
@user.getEmail()
@user.getMailingAddress
@user.getPhoneNumber
@user.getFaxNumber
@user.getResearchFields
@user.getHighestDegree
}


CtrlInterpolate → Tone
Tone.CtrlInterpolate will interpolate between given values based on the "index" property. Passing in an array or object literal will interpolate each of the parameters. Note (i.e. "C3") and Time (i.e. "4n + 2") can be interpolated. All other values are assumed to be numbers.
new
Tone.CtrlInterpolate
(values, index)
values
{Array}
index
{Positive}
The array of values to interpolate over
The initial interpolation index.
code
var interp = new Tone.CtrlInterpolate([0, 2, 9, 4]);
interp.index = 0.75;
interp.value; //returns 1.5
code
var interp = new Tone.CtrlInterpolate([
[2, 4, 5],
[9, 3, 2],
]);
default values
index:0
values:"[]"
members
.values
{Array}
The values to interpolate between
.index
{Positive}
The interpolated index between values. For example: a value of 1.5 would interpolate equally between the value at index 1 and the value at index 2.
code
interp.index = 0;
interp.value; //returns the value at 0
interp.index = 0.5;
interp.value; //returns the value between indices 0 and 1.
.value
{*}
READ ONLY
The current interpolated value based on the index
methods


Team: Charlotte Hornets
Position: Guard
Height: 5' 3"
Weight: 140 lbs.
Born: 1/9/65, Baltimore, Maryland
College: Wake Forest
| Season | G | Min | FG | 3pt | FT | Reb | Ast | Stl | Blk | Tot | PG |
| 95-96 | 6 | 77 | .375 | .000 | 1.000 | 7 | 19 | 2 | 0 | 14 | 2.3 |
| CAREER | 644 | 19500 | .460 | .153 | .813 | 1834 | 5488 | 1110 | 29 | 5396 | 8.4 |