Servlet30 20081218

Servlet 3.0 ``

Rajiv Mordani
Servlet Specification lead
Senior Staff Engineer

Agenda
• Overview
• Pluggability
• Ease of Development
• Async support
• Security
• Status
• Summary

Sun Proprietary/Confidential: Internal Use Only 2

Overview
• Java Servlet 3.0 API – JSR 315
• Has about 20 members in the expert group with a good mix of
representation from the major Java™ EE vendors, web container
vendors and individual web framework authors
• Main areas of improvements and additions are -
> Pluggability
> Ease of Development
> Async support
> Security
• Specification in Public Review and things can change


Agenda
• Overview
• Pluggability
• Async support
• Security
• Status
• Summary


Pluggability
• Make it possible to use frameworks / libraries without boiler plate
configuration that needs to be added to the descriptor
• Modularize web.xml to allow frameworks to have their own artifacts
defined and self-contained within the framework jar
• Add APIs to ServletContext that allow addition of Servlets and
Filters at context initialization time
• Alternately use annotations to declare components that will be
discovered at deployment / runtime by the container


Pluggability – Modularization of
web.xml
• Current users of frameworks today need to have boiler plate
configuration in the web.xml, the deployment descriptor for the
application, to use a framework
• For example,
> to use a framework the developer needs to define a servlet, typically a controller
servlet.
> Define Filters, to do logging or a filter to implement security constraints
> Define listeners so that appropriate action can be taken at different points in the
application / component's life cycle.
• Monolithic web.xml can become complex as dependencies increase
• Frameworks need to document the boiler plate configuration


Pluggability - web-fragment.xml
• In servlet 3.0 we now have a web-fragment.xml, that a framework /
library can bundle
• Defines all the artifacts it needs (ala boiler plate configuration)
• Included in the framework in the META-INF/services directory
• Container responsible for discovering the fragments and assembling the
deployment descriptor for the application
• Essentially almost identical to the web.xml but the top level element is
web-fragment as opposed to web-app
• Frameworks now have the deployment configuration included in itself
• Container scans WEB-INF/lib of the application for these fragments and
assembles the descriptor for the application


Pluggability – web-fragment.xml
sample
<web-fragment>
<servlet>
<servlet-name>welcome</servlet-name>
<servlet-class>
WelcomeServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>welcome</servlet-name>
<url-pattern>/Welcome</url-pattern>
</servlet-mapping>
...
</web-fragment>


Rules for merging
• Defined in the public review of the specification
• web.xml takes precedence over web-fragment.xml
• No ordering defined for web-fragment.xml
• If ordering of listeners / filters are important then they MUST be defined
in the web.xml
• Container scans for the fragments
• If you don't want fragments to be scanned, everything MUST be
specified in the web.xml and the metadata-complete MUST be set to
true in the web.xml
• This will also turn off scanning of annotations
> Works in a mode compatible with servlet 2.5
> Can be used in production systems when you are no longer changing any of
these features
• Can enable / disable certain servlets if you don't want them deployed
from a framework using the enable flag in web.xml

Pluggability – Configuration
methods added to ServletContext
• In addition to the modularization of web.xml, new methods have been
added to ServletContext to declare and configure Servlets and
Filters
• Can only be invoked at context initialization time
• Allows a (framework) developer to
> Declare a new Servlet programatically
> Define the parameters for it (init params, urlPatterns, etc)
> Declare a Filter
> Define the parameters for it (init params, urlPatterns, etc)
• Enables applications / frameworks to be able to dynamically add
Servlets and Fiters.


ServletContext API usage sample
@WebServletContextListener
public class MyListener {
public void contextInitialized (ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
sc.addServlet(quot;myServletquot;,
                       quot;Sample servletquot;,
                     quot;foo.bar.MyServletquot;,
                        null, -1);
sc.addServletMapping(quot;myServletquot;,
new String[] {quot;/urlpattern/*quot;});
}
}


ServletContext API usage sample
– changes post public review
@WebServletContextListener
public class MyListener {
public void contextInitialized (ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
ServletRegistration sr = sc.addServlet(quot;NewServletquot;,
quot;test.NewServletquot;);
sr.setInitParameter(quot;servletInitNamequot;, quot;servletInitValuequot;);
sc.addServletMapping(quot;NewServletquot;, new String[] {quot;/newServletquot;});

FilterRegistration fr = sc.addFilter(quot;NewFilterquot;,
quot;test.NewFilterquot;);
fr.setInitParameter(quot;filterInitNamequot;, quot;filterInitValuequot;);
sc.addFilterMappingForServletNames(quot;NewFilterquot;,
EnumSet.of(DispatcherType.REQUEST), true, quot;NewServletquot;);

}
} Sun Proprietary/Confidential: Internal Use Only 12

Agenda
• Overview
• Pluggability
• Async support
• Security
• Status
• Summary


Ease of Development
• Focus on Ease of Development in the Servlet 3.0 API
• Enhance the API to use the new language features introduced since
Java SE 5
• Annotations for declarative style of programming
• Generics for better type safety in the API where possible without
breaking backwards compatibility
• Make descriptors optional
• Better defaults and conventions for configuration


Ease of Development – use of
annotations
• Specification defines annotations to declare, Servlet, Filter,
ServletContextListener and security constraints.
• @WebServlet annotation for defining a servlet
• The servlet annotation MUST contain at a minimum the url pattern for
the servlet.
• All other fields optional with reasonable defaults
> For example, the default name of the servlet, if not specified, is the fully qualified
class name
• Class MUST still extends HttpServlet
> Method contracts for doGet, doPost etc still derived from the abstract
class
• Can use the web.xml to override values specified in the annotations
> Don't need to recompile code to change configuration at deployment time


Servlet example - 2.5
web.xml
public class SimpleSample <web-app>
extends HttpServlet { <servlet>
<servlet-name>      MyServlet
public void doGet
    (HttpServletRequest req, </servlet-name>
     HttpServletResponse res) <servlet-class>
    { samples.SimpleSample
</servlet-class>
</servlet>
}
<servlet-mapping>
} <servlet-name>
MyServlet
</servlet-name>
<url-pattern>
/MyApp
</url-pattern>
</servlet-mapping>
...
</web-app>

Servlet example - 3.0
@Servlet(“/foo”)
public class SimpleSample extends HttpServlet {
public void doGet(HttpServletRequest req,
HttpServletResponse res)
{

}
}


Agenda
• Overview
• Pluggability
• Async support
• Security
• Status
• Summary


Async Support – Use cases
• Wait for a resource to become available (JDBC, call to webservice)
• Generate response asynchronously
• Use the existing frameworks to generate responses after waiting for the
async operation to complete


Async - API
• Annotation attributes in the @WebServlet and
@ServletFilter annotations that indicates if a Servlet or a
Filter supports async. The attribute is asyncSupported.
• To initiate an async operation there are methods on
ServletRequest - startAsync(req, res) and
startAsync()
• Call to startAsync returns an AsyncContext initialized with
the request and response objects passed to the startAsync call.
• AsyncContext.forward(path) and
AsyncContext.forward() that forwards the request back to
the container so you can use frameworks like JSP to generate the
response.
• AsyncContext.complete() indicates that the developer is
done processing the request and generating the appropriate response.

Async API - contd.
• There are a few more methods in ServletRequest like
isAsyncSupported and isAsyncStarted that can be used
by applications to determine if async operations are supported or
started.
• There is also a new listener - AsyncListener that applications can
use to get notified of when async processing is completed or if a timeout
occurs.


Async API usage
• Initiate async processing using
> startAsync(req, res)
> startAsync().
• startAsync() with no parameters implicitly uses the original
request and response
• startAsync(req, res) uses the request and response
objects passed in.
• The request and response passed in can be wrapped by filters or other
servlets earlier in the request processing chain.
• AsyncContext is initialized appropriately with the request and
response depending on the method used.
• When wrapping the response and calling the no arguments
startAsync() if any data has been written to the wrapped
response and not flushed to the underlying response stream you could
lose the data.. Sun Proprietary/Confidential: Internal Use Only 22

Async API usage - contd
• After the async processing is over you can forward the request back to
run in the context of the web container.
• there are three methods that are available in the AsyncContext
that enable this.
> forward() no args forwards back to the quot;original urlquot; or if a forward
(AsyncContext or RequestDispatcher forward) has occured
after an async context has been initialized then the no args forward will forward
to the path that was used by the AsyncContext /
RequestDispatcher to forward to.
> forward(path) forwards to the path relative to the context of the request
> forward(ServletContext, path) forwards to the path relative to
the context specified. Below is an example that shows a simple web application
that is waiting for a webservice call to return and then rendering the response


Async API example
@WebServlet(“/foo”, public class AsyncWebService
asyncSupported=true) implements Runnable {
public class SimpleSample AsyncContext ctx;
extends HttpServlet {
public
public void doGet AsyncWebService(AsyncContex
    (HttpServletRequest req, t ctx) {
     HttpServletResponse res)
    { this.ctx = ctx;
... }
AsyncContext aCtx = public void run() {
request.startAsync(req, res); // Invoke web
ScheduledThreadPoolExecutor service and save result in
executor = new request attribute
ScheduledThreadPoolExecutor(1 // Forward the
0); request to render the
executor.execute(new result to a JSP.
AsyncWebService(aCtx)); ctx.forward(quot;/render.jspquot;);
} }
} } 24
Sun Proprietary/Confidential: Internal Use Only

Agenda
• Overview
• Pluggability
• Async support
• Security
• Status
• Summary


Security
• Not in the public review of the spec – still not closed in the EG
• Looking to add programattic login and logout
• Method can be used to force a login and ability to logout
• Proposal is to add login and logout methods to
HttpServletRequest, HttpSession (logout only)
• Login method intended to allow an application or framework to force a
container mediated authentication from within an unconstrained request
context
• Login requires access to the HttpResponse object to set the
www-authenticate header.
> Available through new methods added to the request to give access to the
corresponding response object
• Logout methods are provided to allow an application to reset the
authentication state of a request without requiring that authentication be
bound to an HttpSession

Security - contd.
• Add support for annotations defined in Java EE 5 -
@RolesAllowed, @PermitAll, @DenyAll
• Added support for HttpOnlyCookies
• Prevents access to the cookie from client side scripting code
• Prevents cross-site scripting attacks.
• Method added to Cookie to set and query if it is an
HttpOnly cookie


Agenda
• Overview
• Pluggability
• Async support
• Security
• Status
• Summary


Status
• Specification currently in Public Review
• Proposed final draft and final release will be aligned with Java EE 6
• Implementation of a lot of the Public Review version of the specification
is available today in the GlassFish trunk build.
> Shing Wai and I are thinking of doing a screencast to demo the features
available today after the holidays


Summary
• Lot of exciting things happening in the Java™ Servlet 3.0 API
> Pluggability for frameworks
> Ease of Development for developers
> Async support
> Security enhancements
• Make the life of the framework developer and users of the frameworks
much easier
• Implementation being done in the open source as part of GlassFish
project.


Resources
• JCP page
> http://jcp.org/en/jsr/detail?id=315
• Feedback alias
> jsr-315-comments@jcp.org
• Mailing list for GlassFish related webtier issues
> webtier@glassfish.dev.java.net
• Blogs
> Rajiv - http://weblogs.java.net/blog/mode
> Shing Wai - http://blogs.sun.com/swchan
> Jan Luehe - http://blogs.sun.com/jluehe
> Jeanfrancois Arcand - http://weblogs.java.net/blog/jfarcand
> Aggregated feed for GlassFish webtier -
http://planets.sun.com/glassfishwebtier/group/blogs/ or
http://feeds.feedburner.com/GlassFish-Webtier

Servlet30 20081218

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (8)

Destaque

Destaque (20)

Semelhante a Servlet30 20081218

Semelhante a Servlet30 20081218 (20)

Último

Último (20)

Servlet30 20081218