Greg Wilkins from Webtide blogged about the pluggability mechanism and raised an issue with the auto-scanning. Hopefully this blog will make the argument for the simple scanning of annotations and web-fragments and argue against the case of having a more flexible scheme in this release of the servlet specification.
I will start with the annotation case first and then talk about the web-fragments. When you use annotations to declare servlets and Filters then you must have a url-mapping / FilterMapping attribute on the corresponding servlet / Filter. In this way there is no convention by which a servlet is exposed without having an explicit mapping. Also , as with the rest of the Java EE platform, specifically technologies like EJB and Web Services, the deployment descriptor is used to override information that is specified via annotations. So if you have a servlet that is declared via annotations during development and now you need to change one attribute of the servlet when you go from development to production, you don't need to modify the code. Instead you override the configuration using the web.xml file. In the example below I show how this can be used -
@Servlet(url-mapping="/foo")
public class MyServlet {
@GET
public void handleGet(HttpServletRequest req, HttpServletResponse res) {
...
}
}
At deployment time say you want to override the url-mapping for the servlet defined above. The way you would do that would be by defining the new mapping for the servlet in the web.xml as shown below -
<web-app>
<servlet-mapping>
<servlet-name>
MyServlet
</servlet-name>
<url-pattern>
/MyApp
</url-pattern>
</servlet-mapping>
</web-app>
If you didn't want any of the annotations to be processed at all by the container and wanted to specify all the configuration via the deployment descriptor, then, like with the rest of the Java EE 5 platform, we have the metadata-complete element in the descriptor. If the element is present and set to "true" then the container will not process any annotations and just use the configuration specified in the descriptor. This provides a way disable the auto-scanning for those that have concerns about performance, and security. This is consistent with what we have today in Java EE 5 platform and has worked well with EJBs and JAX-WS (Web Services APIs). We have not received any negative feedback about security and performance being an issue. Web Services are endpoints that are exposed on the web so the argument someone makes about there not being a security hole in EJB does not stand true for Web Services.
The second issue is about auto-scanning of web-fragments. The early draft of the specification says that the container needs to process web-fragments and make available the servlets, filters an listeners defined via the fragments. As discussed in my earlier post, this helps with use of frameworks. Currently the early draft of the specification says that the same flag - metadata-complete controls both the scanning of annotations and fragments. I still think that is sufficient for the developers. However during JavaOne we had an expert group face-to-face meeting and discussed the possibility of having another flag to control the scanning of web fragments and use the metadata-complete just to control scanning of annotations. Again similar to metadata-complete this flag would control whether to scan for web-fragments or not. If you choose not to scan the web-fragments then you would need to specify the entire metadata that you need in in the web.xml of the application, a-la metadata-complete :). For those that have major security concerns this would probably be the route to go because even if you do have the include mechanism there would be no way to specify just one servlet from the jar file. The container would still scan for all the servlets, filters and listeners from the framework available. The concept of "trusting" certain frameworks doesn't seem to solve the problem. Let's take Spring for example - if you choose Spring as the framework but didn't want one of the servlets defined in Spring to be available. The include mechanism would not work for you. You would have to fall back on defining everything in the web.xml of the application anyways. The benefit that the include proposal from Greg Wilkins is very little specially if the main concern is that servlets and filters are being exposed without the user intending to do so. I think that it is the problem of the framework developer and not the user of the framework to make sure that they don't expose certain types of components. By using a flag to control scanning you can effectively get what the include mechanism provides except you don't get partial scanning of only a certain set of jars. The include mechanism would probably only make the descriptor more verbose in having to list the jars you want scanned.
Another mechanism that came up during the face-to-face which hasn't been still talked about in the expert group is the concept of disabling servlets and filters in the application's web.xml. For example we could have in the application's web.xml the following -
<servlet>
<servlet-name>FrameworkServlet</servlet-name>
<enabled>false</enabled>
</servlet>
This way some of the servlets that aren't needed in production can be disabled via the main web.xml of the application and the security issue can be mitigated while keeping things simple.]]>
To overcome this issue in servlet 3.0 we are adding a new feature that allows having more than one web.xml, or as it is being referred in the specification as web fragments. A framework can define it's own web.xml that declares the necessary components for the framework that is then included for use in the web applicaton. At deployment the container is responsible for discovering the web.xml fragments and processing them. A new element is being added to the schema for web applications - web-fragment that can define servlets, filters listeners. Below is a simple example of such a fragment.
<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>
In addition to changes to modularize the web.xml there are also annotations being defined to declare servlets (@Servlet), filters (@ServletFilter) and the annotations have all the attributes defined to make web.xml optional. These attributes contain information like url-mapping, init-params and other information that would typically be defined in the deployment descriptor. This way Servlets, filters etc can be defined entirely using annotations and would be picked up from the WEB-INF/classes or WEB-INF/lib directory.
Along with the changes mentioned above there are few new APIs to also allow programmatic addition of Servlets and Filters at start up time of an application. API changes for adding configuration are added to the ServletContext class and are listed here below:
ServletContext:
addServlet
addServletMapping
addFilter
addFilterMapping
Below is an example that shows how the APIs defined in ServletContext can be used.
@ServletContextListener
public class MyListener {
public void contextInitialized (ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
sc.addServlet("myServlet",
"Sample servlet",
"foo.bar.MyServlet",
null, -1);
sc.addServletMapping("myServlet",
new String[] {"/urlpattern/*"});
}
}
@ServletContextListener
public class MyListener {
public void contextInitialized (ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
sc.addFilter("myFilter",
"Sample Filter",
"foo.bar.MyFilter",
null);
sc.addFilterMapping("myFilter",
new String[] {"/urlpattern/*"},
“myServlet”,
DispatcherType.REQUEST, false);
}
}
As you can see with the changes above now the onus is on the framework authors to make sure that they declare and make available the components and be self sufficient. As for the developers / users of the frameworks they now just need to include these libraries in their application and start using it.]]>
Along with the changes mentioned above there are few new APIs to also allow programmatic addition of Servlets and Filters at start up time of an application.
API changes for configuration addition:
ServletContext: addServlet, addServletMapping, addFilter, addFilterMapping
package samples;
import javax.servlet.http.annotation.*;
@Servlet(urlMappings={"/foo"})
public class SimpleSample {
}
The use of annotations makes web.xml optional and a developer does not really need to use it unless they want to change some configuration without changing code - for example at deployment time. Also, as with all the other parts of the Java EE platform, the descriptor always overrides the metadata provided via use of annotations.
Note: For details about all the API changes look at the javadocs (once the spec is available from the jcp website). The exact method signatures aren't duplicated here. Instead just the names are here to give an idea of the kind of changes.]]>
<GLASSFISH_HOME>/updatecenter/bin directory and launch updatetool.
Once the update tool is up and running choose the components that you want to install and just click on the install button. That's it. The instance of GlassFish will now be enabled with the components that you chose to install. You can build, deploy and run applications using the technologies just as before. Give it a try and let us know what you think about it.]]>
Unlike some of the previous releases of the specification which were just maintenance of the specification we will be revising the servlet API to use some of the modern language features. One of the key features that is planned for this release is plugability and extensibility which is also one of the main theme for Java EE 6.
We will be using the open source model for development of the implementation, making it available early and often via project GlassFish for developers to try out the new features and give us feedback. If you would like to participate in the JSR please fill in your nominations to become part of the expert group here. Please note that you need to be a JCP member to be able to participate in the JSR. ]]>
See Paul's blog for an explanation about the name.]]>
Danny also has a list of the
top ten new features in Java SE 6.
]]>
Before we move to the discussion of jMaki and JSF-Extensions a quick note on JSP and JSF and when to use which one. Generally JSP is used when you want to have some dynamic content generated in your page but not necessarily a lot of user interaction. JSF on the other hand is designed for user interaction and has a very well defined request processing life cycle. One key design requirement for JSF was scalability of applications. While this is generally true, however take care while designing applications as it can start off with some dynamic content and can quickly develop into an application that has a lot of user interaction.
jMaki and JSF-Extensions both AJAX enable JSPs and JSF components. So how do you decide when to use jMaki and when to use JSF-Extensions? jMaki and JSF-extensions work well together. Through this document this assertion will become more clear.
The name, jMaki, was derived from "j," for Java, and "maki," a Japanese word for “wrap” that is commonly used when descriping the roll type of sushi. jMaki acts as a wrapper for existing JavaScript libraries giving access to the JavaScript widgets from JSP pages or JSF components. jMaki today provides access to common widgets like the Yahoo map widget and Google Search widgets among others. It also provides access to widgets from other AJAX frameworks like the Dojo toolkit. jMaki will support future JavaScript frameworks and it allows you to use these frameworks together in the same page. jMaki enables the use of these widgets in Java using it either as a JSP tag or as a JSF component. jMaki is specially useful when your application uses only JSPs and Servlets and does not use JSF. jMaki when used as part of a JSF component has access to all the backend APIs in Java EE like persistence while adding dynamism to the front end of the appliation. Below is an example of how to use jMaki from within JSPs and JSF.
Below is a code snippet that shows how to use the scriptaculous inplace editor widget from within a JSP using jMaki -
<%@page contentType="text/html"%>
<%@page pageEncoding="UTF-8"%>
<%@ taglib prefix="a" uri="http://java.sun.com/jmaki" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP Page</title>
</head>
<body>
<h1>JSP Page</h1>
<a:ajax type="scriptaculous" name="inplace" service="inplaceService.jsp" value="click me to replace"/ >
</body>
</html>
The code in red above is of particular interest showing the usage of
jMaki. First we declare jMaki as a tag in the JSP page
by using the @taglib directive.
Once we declare that we then use it in the JSP page by including it using
the <a:ajax .... > directive that specifies
type of Javascript library that you want to use (in this case Scriptaculous) with
all the other attributes that are needed by jMaki. For details on the attributes to
use with the jMaki tag see
ajax.dev.java.net/developer.html
Below is an example of how to use jMaki in a JSF data table from a resultset. The
same jMaki widget used above (the scriptacuous inplace editor) is used in the
data table here to set a new value for one of the columns of the table.
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib prefix="jsfExt" uri="http://java.sun.com/jsf/extensions/avatar" %>
<%@ taglib uri="http://java.sun.com/blueprints/ui" prefix="d" %>
<%@ taglib prefix="a" uri="http://java.sun.com/jmaki-jsf" %>
<f:view>
<html>
<head>
<title>Result Set Example
<link rel="stylesheet" type="text/css"
href='<%= request.getContextPath() + "/result-set.css" %>'>
<script type="text/javascript"
src='<%= request.getContextPath() + "/devtime.js" %>'>
</head>
<body bgcolor="white">
<a href='<%= request.getContextPath() + "/index.html" %>'>Back to home page.
<hr>
<h3>The Scroller Component
<h:form id="form">
Rendered via Faces components:
<jsfExt:ajaxZone id="subview1" style="position: relative;"
postInstallHook="postInstallHook">
<h:dataTable columnClasses="list-column-center,list-column-center,
list-column-center, list-column-center"
headerClass="list-header"
rowClasses="list-row-even,list-row-odd"
styleClass="list-background"
id="table"
rows="20"
binding="#{ResultSetBean.data}"
value="#{ResultSetBean.list}"
var="customer">
<h:column>
<f:facet name="header">
<h:outputText value="Account Id"/>
</f:facet>
<h:outputText id="accountId"
value="#{customer.accountId}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Customer Name"/>
</f:facet>
<a:ajax type="scriptaculous" name="inplace" value="#{customer.name}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Symbol"/>
</f:facet>
<h:outputText id="symbol"
value="#{customer.symbol}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Total Sales"/>
</f:facet>
<h:outputText id="totalSales"
value="#{customer.totalSales}"/>
</h:column>
</h:dataTable>
</jsfExt:ajaxZone>
<jsfExt:ajaxZone id="subview2">
<d:scroller id="scroller" navFacetOrientation="NORTH" for="table"
actionListener="#{ResultSetBean.processScrollEvent}">
<f:facet name="header">
<h:panelGroup>
<h:outputText value="Account Id"/>
<h:outputText value="Customer Name"/>
<h:outputText value="Symbol"/>
<h:outputText value="Total Sales"/>
</h:panelGroup>
</f:facet>
<f:facet name="next">
<h:panelGroup>
<h:outputText value="Next"/>
<h:graphicImage url="/images/arrow-right.gif" />
</h:panelGroup>
</f:facet>
<f:facet name="previous">
<h:panelGroup>
<h:outputText value="Previous"/>
<h:graphicImage url="/images/arrow-left.gif" />
</h:panelGroup>
</f:facet>
<f:facet name="number">
<!-- You can put a panel here if you like -->
</f:facet>
<f:facet name="current">
<h:panelGroup>
<h:graphicImage url="/images/duke.gif" />
</h:panelGroup>
</f:facet>
</d:scroller>
<script type='text/javascript'>
document.forms[0].submit = function() {};
var a = $('form:subview2').getElementsByTagName('a');
$A(a).each(function(e) {
new Faces.Command(e, 'mousedown', { subtrees: 'form:table,form:subview2' });
});
</script>
</jsfExt:ajaxZone>
</h:form>
</body>
</html>
</f:view>
In the example above again looking at the code in red we see how to use jMaki inplace editor on one of the columns of the resultset data table.
JSF-Extensions is another project that is intended to AJAX enable JSF
components. The JSF-Extensions project builds on the JSF framework.
If the application that you want to AJAX enable is already using the JSF
framework then jsf-extensions is a good choice. jsf-extensions introduces the notion
of partial updatable sub-views. jsf-extensions is used as a tag library and introduces
the concept of ajaxZones that are used to define subtrees that allow partial updates
rather than the traditional full page refresh. The approach taken by JSF-Extensions is to
create a custom Lifecycle AjaxLifecycle that decoarates the standard
Lifecycle to AJAX enable a JSF application. The
AjaxLifecycle checks to see if a request is an AJAX
request by inspecting request headers to see if it is an asynchronous request.
If the header is not set then the standard Lifecycle methods are invoked that does
normal JSF processing. Below we see an example of how to use jsf-extensions.
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib prefix="jsfExt" uri="http://java.sun.com/jsf/extensions/avatar" %>
<%@ taglib uri="http://java.sun.com/blueprints/ui" prefix="d" %>
<%@ taglib prefix="a" uri="http://java.sun.com/jmaki-jsf" %>
<f:view>
<html>
<head>
<title>Result Set Example
<link rel="stylesheet" type="text/css"
href='<%= request.getContextPath() + "/result-set.css" %>'>
<script type="text/javascript"
src='<%= request.getContextPath() + "/devtime.js" %>'>
</head>
<body bgcolor="white">
<a href='<%= request.getContextPath() + "/index.html" %>'>Back to home page.
<hr>
<h3>The Scroller Component
<h:form id="form">
Rendered via Faces components:
<jsfExt:ajaxZone id="subview1" style="position: relative;"
postInstallHook="postInstallHook">
<h:dataTable columnClasses="list-column-center,list-column-center,
list-column-center, list-column-center"
headerClass="list-header"
rowClasses="list-row-even,list-row-odd"
styleClass="list-background"
id="table"
rows="20"
binding="#{ResultSetBean.data}"
value="#{ResultSetBean.list}"
var="customer">
<h:column>
<f:facet name="header">
<h:outputText value="Account Id"/>
</f:facet>
<h:outputText id="accountId"
value="#{customer.accountId}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Customer Name"/>
</f:facet>
<a:ajax type="scriptaculous" name="inplace" value="#{customer.name}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Symbol"/>
</f:facet>
<h:outputText id="symbol"
value="#{customer.symbol}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Total Sales"/>
</f:facet>
<h:outputText id="totalSales"
value="#{customer.totalSales}"/>
</h:column>
</h:dataTable>
</jsfExt:ajaxZone>
<jsfExt:ajaxZone id="subview2">
<d:scroller id="scroller" navFacetOrientation="NORTH" for="table"
actionListener="#{ResultSetBean.processScrollEvent}">
<f:facet name="header">
<h:panelGroup>
<h:outputText value="Account Id"/>
<h:outputText value="Customer Name"/>
<h:outputText value="Symbol"/>
<h:outputText value="Total Sales"/>
</h:panelGroup>
</f:facet>
<f:facet name="next">
<h:panelGroup>
<h:outputText value="Next"/>
<h:graphicImage url="/images/arrow-right.gif" />
</h:panelGroup>
</f:facet>
<f:facet name="previous">
<h:panelGroup>
<h:outputText value="Previous"/>
<h:graphicImage url="/images/arrow-left.gif" />
</h:panelGroup>
</f:facet>
<f:facet name="number">
<!-- You can put a panel here if you like -->
</f:facet>
<f:facet name="current">
<h:panelGroup>
<h:graphicImage url="/images/duke.gif" />
</h:panelGroup>
</f:facet>
</d:scroller>
<script type='text/javascript'>
document.forms[0].submit = function() {};
var a = $('form:subview2').getElementsByTagName('a');
$A(a).each(function(e) {
new Faces.Command(e, 'mousedown', { subtrees: 'form:table,form:subview2' });
});
</script>
</jsfExt:ajaxZone>
</h:form>
</body>
</html>
</f:view>
The code in red above is of particular interest showing the usage of jsf-extensions.
First we declare jsf-extensions component in the JSP page by using the @taglib
directive. Once we declare that we then use jsf-extensions in the JSP page by
including it using the <jsfExt:ajaxZone .... > directive. For details on the attributes
to use with the jsf-extensions tag see
jsf-extensions.dev.java.net/nonav/mvn/ajax/tlddocs/index.html
As seen above jMaki and jsf-extensions work well with each other. Also there are situations where you could use on or the other depending on the architecture of the application.]]>