 |
Got Servlets?
Posted by gmurray71 on July 12, 2005 at 11:04 PM | Comments (36)
Servlets are one of the older APIs that is now part of Java Enterprise Edition (Java EE).
Look at JSF, Struts, Tapestry, Velocity, Shale, or any of the other Java EE or
Java based web frameworks and you will see servlets at the core.
The servlet API has stood the test of time because it was designed good from
the start and has evolved slowly. As part of Java EE 5.0 servlets
will be undergoing a maintenance release. At the same time the servlet EG is starting to
think about the direction to take the next major Servlet release in the future.
Some suggestions we have had that we are looking into for the next major
release of servlets include:
- Multipart-Support - File upload support.
- Improved Security - This has been an area where we have wanted to
refine for sometime. This may includes APIs for programatic login.
- Self Registration - The ability to create accounts and have a
remember me cookie.
- Annotation Support - Make servlets easier to define by reducing the
number of artifacts a developer needs to create.
The list above is not an exhaustive list but should give an idea as to the direction we see the Servlet API going. As the Servlet specification lead I would also like to invite suggestions from the community at large.
How are you using Servlets? Where do you want them to go?
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Your second and third points are at cross-purposes. Enhanced cookie support, especially for registration and login, would just make it easier for programmers to develop insecure and broken systems. Look to HTTP authentication instead for login, and base logins on resources rather than sessions. In other words, make the servlet API more RESTful, not less. Cookie-based accounts are going in the wrong direction.
Posted by: elharo on July 13, 2005 at 04:27 AM
-
I've always wondered why http-servlets are the only kinds around.
Posted by: tobega on July 13, 2005 at 06:20 AM
-
There should be some way to get the host address and other related server information from the ServletContext - so we can retrieve it w/o a StartupListener.
Posted by: rsanheim on July 13, 2005 at 06:36 AM
-
So when I say self registration here I am referring to a cookie that is left on the client that contains merely a username. This cookie would only be left on the client if the end user chooses to do so (think of this as a "remember me next time checkbox"). This very common feature used in may web applications. For example, when you go to Yahoo or Amazon and it knows your username and in some cases the username might be used to direct you to special offers or customized content. This would by no means replace HTTP based authentication. HTTP authentication will still be required to access protected resources with the servlet API. We don't plan on changing that.
As for Http servlets there aren't many other variations of the servlets out there. There are SIP Servlets which extend the Servlet API. Having a flexible API makes the Servlets versatile and capable of handling whatever the future may bring.
Posted by: gmurray71 on July 13, 2005 at 06:51 AM
-
#1 thing for me would be to allow a container-managed authentication model - ie [auth-method]CONTAINER[/auth-method]. Taking the login method out of the webapp allows container-level integration with (eg) CAS, Athens, and the like, instead of relying on servlet filters, without waiting for a new revision of the servlet spec to add each one.
Posted by: ba22a on July 13, 2005 at 06:52 AM
-
I'd like to see a mechanism for deploying non-HTTP servlets.
While we see support for well defined protocols in things like the SipServlet spec, I'd like to be able to deploy a servlet that handles a custom protocol over TCP/IP into my servlet container.
I understand that this has side effects (e.g. the container can probably not serve any other type of requests (e.g. HTTP requests) if it does not have a way of distinguishing between my custom protocol and other formal protocols. However, I'd be quite happy to have all incoming requests routed to this one servlet.
The reason for this: there are still an awful lot of applications around that work with some kind of custom protocol by just opening a TCP/IP connection and dumping text or binary data. Being able to service such requests within a (servlet) container is much more convenient than having to write my own server application managing a ServerSocket for each of those.
Depending on the container I select, I might get some of the management and monitoring support that I can get for HttpServlets today.
Posted by: okamps on July 13, 2005 at 07:33 AM
-
Greg,
One small cosmetic change that I think would help a lot (specially when you are teaching servlets and JSP) is to create an interface for attribute containers (such as ServletContext, HttpSession, ServletRequest and PageRequest implement it):
public interface AttributeContainer() {
void setAttribute( String name, Object attribute );
Object getAttribute( String name );
Enumeration getAttributeNames();
void removeAttribute( String name );
}
The cost of implementing it would be almost none - only PageContext doesn't already have getAttributeNames() and it would be easy to implement it as { return getAttributeNamesInScope( PAGE_SCOPE ) }; the only hard job would be defining a decent name for this interface, as container is already overused on J2EE (maybe AttributesHolder or AttributesManager would make more sense).
-- Felipe
PS: I had commented this suggestion with some web-tier folks last year at JavaOne, but I'm not sure if I mailed it to you.
Posted by: felipeal on July 13, 2005 at 10:25 AM
-
Something like:
public class MyServlet .... {
@EJB PersonManagement personMngt;
@Inject DataSource myDb;
@GetMethod public void myOwnDoGet(...) {
}
@PostMethod public void myOwnDoPost(...) {
}
}
Also, regex in web.xml mappings, allow to do EXCLUDES servlet-mappings. So:
...
/*
/login
Also, add generics to request.getParameter and request.set/getAttribute methods:
public T getAttribute(Key key);
So in my servlet I can write:
Date d = request.getAttribute(Key.create("loginDate"));
Or something like it...
Cheers,
Arik.
Posted by: arikk on July 13, 2005 at 10:31 AM
-
Something like:
public class MyServlet .... {
@EJB PersonManagement personMngt;
@Inject DataSource myDb;
@GetMethod public void myOwnDoGet(...) {
}
@PostMethod public void myOwnDoPost(...) {
}
}
Also, regex in web.xml mappings, allow to do EXCLUDES servlet-mappings. So:
...
/*
/login
Also, add generics to request.getParameter and request.set/getAttribute methods:
public T getAttribute(Key key);
So in my servlet I can write:
Date d = request.getAttribute(Key.create("loginDate"));
Or something like it...
Cheers,
Arik.
Posted by: arikk on July 13, 2005 at 10:34 AM
-
The new servlet spec should work with NIO. Let's change it from a pull model to a push model.
For instance, instead of a getHeaders() method, there should be a HeadersListener interface. Those components that are interested in the headers can simply register for those events.
A goal of the new servlet spec should be to get rid of thread pools in a servlet container. Use NIO and a push/event model.
Posted by: sethladd on July 13, 2005 at 12:50 PM
-
Oh, and definitely +1 to regex's used for servlet and filter mapping.
BTW I believe the Jetty servlet container has done some excellent work on exploring how NIO will fit into a new servlet spec.
Posted by: sethladd on July 13, 2005 at 12:51 PM
-
In reference to Anotations Injection
public class MyServlet .... {
@EJB PersonManagement personMngt;
@Resource DataSource myDb;
@GetMethod public void myOwnDoGet(...) {
}
@PostMethod public void myOwnDoPost(...) {
}
}
So just a note on your example. We are considering supporting a few annotations defined in JSR 250 (Common Annotations) in the Servlet 2.5 Maintenance Release.
In Java EE 5.0 web containers (Servlet 2.5) we are considering an @Resource annotation that provide dependency injection in the same way the @Inject tag you showed in your code snippet. This will allow you to inject DataSources, access to JMS queues, and Environment entries into container managed objects such as servlets and listeners. @EJB will also provide easy definitions on Java EE 5.0 enabled web containers. Stay tuned for more details as the maintenance release progresses.
As for the @GetMethod and @PostMethod we haven't gone as far as to define this level yet. The goal of course would be to make the API easier to get jump started with and reduce the need to use deployment descriptors. The web.xml is not going away anytime soon but it would be nice to investigate what can be done to reduce the need for it.
Regarding NIO. We hope to investigate this as well but there will be some issues as can be seen in the blog NIO and the Servlet API by one of the Servlet Expert Group members and creator of the Jetty Servlet Server. This blog a good read.
The Glassfish Web Container is NIO underneath of the Servlet APIs. Jean-Francois talks about this in his blog Grizzly: An HTTP Listener Using Java Technology NIO. Moving forward it will be good to investigate what APIs make sense to expose to the Servlet API and how they may or may not work with the current model.
Posted by: gmurray71 on July 13, 2005 at 05:42 PM
-
JSPs loaded from JARs.
One of the things that drives me nuts about JSPs is that there is no way to break them down into modules and ship them with the code. If I want to include a new module in my WAR file, I also have to copy over the JSPs as well which I find sloppy. One module, one JAR, JSPs and code inclusive.
Posted by: chicagokarl on July 14, 2005 at 02:11 AM
-
I thought servlets are the assembly language of Java web programming. I just want them to be invisible--e.g. no boilerplate in web.xml. Ask the JSF implementors what enhancements, if any, they need.
Posted by: cayhorstmann on July 14, 2005 at 08:09 AM
-
Current httpsession support in spec defines different session for each wedmodule. If application has multiple web modules there will be multiple session objects for a given client and there is no easy way for application to correlate sessions together. For example, if a session in one module timesout and application wants to invalidate sessions in other modules for that client, they cannot achieve that today. Servlet API should provide a notion of ApplicationSession that will have referece to all sessions for a given client. From HttpSession we should be able to get to ApplicationSession and viceversa. SIP Servlet spec already has notion of ApplicationSession(javax.servlet.sip.SipApplicationSession) . Similar programming model can be used in ServletSpec to support httpsessions,sipsessions and other types of sessions. This will help supporting converged applications.
Posted by: srinivas_h on July 14, 2005 at 08:28 AM
-
>> There should be some way to get the host address and
>> other related server information from the ServletContext -
>> so we can retrieve it w/o a StartupListener.
Nice wish, but afaik there's no way to control which DNS aliases are being used to access your app server...
My 2Cent:
full regex support for mappings, including e.g. "/*/*.suffix" (!)
get rid of Enumeration in the API, or at least deprecate those methods using Enumeration. THE TIME HAS COME TO DO IT!
I like the "JSP from .jar" idea too.
Posted by: vict0r on July 14, 2005 at 05:27 PM
-
I have Servlets outlines some of my initial thoughts (sorry, I was going to TrackBack but TrackBacks are still switched off, I think).
Posted by: simongbrown on July 15, 2005 at 01:59 AM
-
First on my list is more powerful mappings. It's been awhile since I've worked with servlets, but I seem to remember hitting limitations with mappings more than once. If memory serves correctly, it is sometimes a problem that you need to specify a default mapping for servlets, but still want the ability to reference static files without the default servlet being invoked.
Second would be more options for configuring properties. Right now you often embed property name/value pairs in the WAR file somewhere. If your customer has a different configuration, they have to expand the WAR, change the values, and then their stuff gets trampled the next time they deploy. An easy way to package configuration settings outside of the WAR file would be nice. So then I could just get in there and edit a properties file and those props would be hot-deployed right away, or I could deploy a new version of my WAR file and my properties file wouldn't be erased.
Posted by: burke_e on July 15, 2005 at 04:39 AM
-
>> There should be some way to get the host address and
>> other related server information from the ServletContext -
>> so we can retrieve it w/o a StartupListener.
>>>>>Nice wish, but afaik there's no way to control which DNS aliases >>>>>are being used to access your app server...
I'm not asking for the full DNS host name, just the IP address would be fine. We can do getServerName and getServerPort from within a servlet request, why not within a start up listener or servlet context? Surely the servlet should be able to ask the container what its ip address is?
Posted by: rsanheim on July 15, 2005 at 09:01 AM
-
Wow I wish I could edit comments here now...
Posted by: rsanheim on July 15, 2005 at 09:01 AM
-
Servlet spec should not require to commit and close the response writer, if request was forwarded from another location (SRV version 2.4, section 8.4) The current spec prevents using good MVC practices with directive, because if included resource forwards to another location to obtain a view, a writer is closed and master page is not rendered fully.
See details in JSP spec mailing list.
I already sent this request to servlets spec group directly, and I got an answer that it will be taken into account. But I thought that it would not hurt to repeat it one more time :)
Posted by: michael_jouravlev on July 16, 2005 at 11:14 AM
-
A poster on the Struts user list was having problems posting comments to this blog, so she asked me to post a link to her blog entry on the subject.
http://www.holoweb.net/laurie/archives/2005/07/16/86
Posted by: craig_mcc on July 16, 2005 at 05:35 PM
-
Here's my Servlet API wishlist for authentication:
Standard support for custom authenticatorsTo integrate with SiteMinder, currently we use Tomcat's custom authenticator support which is a bit of a "hack" (applying the nicest possible term).
Standard way of accessing permission groups beyond "Roles":We have a custom JAAS login module to load account and access information from various sources. Currently to access data beyond the "Roles" group we have to make a separate call after the user logs in because there is no standard way of accessing other permission groups.
+1 on self-registration and "remember me"
Beyond authentication:
Async NIO support
Standard FTPServlet
Apache-style rewrite rules
Posted by: ctrawick on July 18, 2005 at 12:08 PM
-
Better HTML support on java.net would be nice too. ;) My post below got pretty mangled, but it's still readable. To clarify, the first item asks for standard support for custom authenticators, not SiteMinder specifically.
Posted by: ctrawick on July 18, 2005 at 12:13 PM
-
It would be nice to have some sort of session timeout notification mechanism so that requests to a timed out session could be automatically forwarded to a timeout page or a timeout handler which could be specified either declaratively in web.xml or programatically in the application code. The HttpServlet service() method could transparently capture the timeout event and forward it to an application defined handler. This of course should only occur only when a request to a timed out session is detected, and not when a new session is created.
Posted by: branko_juric on July 21, 2005 at 02:28 AM
-
My improvement ideas come from my work on the Java version of ModSecurity (still work in progress):
Server-wide filters/plugins. Servlet filters are a pretty capable technology but they are still an application-level feature. I'd like to see a Java standard for web server-wide plug-ins. There is so much to learn from the Apache web server here.
Server-controlled buffering. Right now it is the application that controls buffering. In some cases (for example when you want to screen all output for security reasons) it is necessary to force buffering upon an application. This is possible to do now, with a filter, but it's not very efficient since buffering is done twice - once in the container and once in the filter. A configuration switch to enforce buffering, together with ability to have direct access to the buffer in the container would possibly offer significant performance enhancements.
Posted by: ivanr on August 08, 2005 at 03:55 AM
-
My vote is for more choice in login methods. BASIC and FORM are need to be supplemented with a mechanism that allows more flexibility, e.g. for the login form to be positioned as an HTML snippet on an unprotected page for instance a home page.
It should also be possible to set SSL encryption for just the login form, to avoid sending clear text passwords, but without enforcing SSL for all protected pages after login. Clear text passwords are an egregious security loophole.
Session hijacking is also a bad (but not as bad) issue, which all non-SSL security level sessions are open to, which leads to a requirement for sensitive data on authenticated users to be handled differently to insensitive data such as the user's first name used in salutations (insensitive) compared to user's credit card info (sensitive).
Currently in any webapp even when on different pages under different security-constraints it is very difficult to handle these 2 seperately without jumping through hoops. The developer must either encrypt everything, just to see a first name salutation, in order to protect the credit card info, or use such mechanisms as an unencrypted first login and an encrypted second login.
I hope that makes sense - it's not an obvious problem but it causes many people to ditch CMS.
Posted by: ahardy66 on August 08, 2005 at 04:45 PM
-
Here is an import suggestion that will save hundred of hours to Developers worldwide based on the recommended HTML (W3C) standards:
Updating the Java Specification to allow the request object to follow a first in first out behavior with "names/values" pairs when retrieving the Request Object, the same way W3C standards recommend:
snips from: http://www.w3.org/TR/html401/interact/forms.html#h-17.13
application/x-www-form-urlencoded
...
2. The control names/values are listed in the order they appear in the document.
Otherwise application following the Java standards such as the Jakarta Project (Apache) are not forced to organized their request objects and limit developers to utilize random name/value pair controls. This is a huge limitation when writing dynamic web applications. Developers should be expecting a sorted list to come out *in the order they appear in the document* as recommended.
Thank you for your interest in that matter,
Jeff Grangier
Posted by: jefou on August 12, 2005 at 07:49 PM
-
Here is an import suggestion that will save hundred of hours to Developers worldwide based on the recommended HTML (W3C) standards:
Updating the Java Specification to allow the request object to follow a first in first out behavior with "names/values" when retrieving the Request Object, the same way W3C standards recommend:
snips from: http://www.w3.org/TR/html401/interact/forms.html#h-17.13
application/x-www-form-urlencoded
...
2. The control names/values are listed in the order they appear in the document.
Otherwise application following the Java standards such as the Jakarta Project (Apache) are not forced to organized their request objects and limit developers to utilize random name/value pair controls. This is a huge limitation when writing dynamic web applications. Developers should be expecting a sorted list to come out *in the order they appear in the document* as recommended.
Thank you for your interest in that matter,
Jeff Grangier
Posted by: jefou on August 12, 2005 at 07:51 PM
-
Another security feature. At present servlet containers cannot regulate how many times a user is allowed to attempt to login.
Nice-to-have enhancements would be:
configurable number of login attempts before lock-out
lock-out period length configurability
Posted by: ahardy66 on August 25, 2005 at 06:10 AM
-
forgot to mention, the previous suggestion would be to foil scripted attacks attempting to guess the password by brute force means.
Posted by: ahardy66 on August 25, 2005 at 06:14 AM
-
The servlet spec is considered low level in these days of web application frameworks. It would be a waste to compete with the frameworks by adopting higher level functionality like self registration.
IMHO, the focus should be making improvements that can not be achieved by the frameworks because of the servlet spec. Some of these are:
Applicaiton wide session. Someone already mentioned this.
A web flow scope, which is wider than a request scope but narrower than session scope. In most frameworks we put the command object or form object in the session. All hell breaks lose when the user opens a form in two browser windows. For single forms this can be handled with hiddens, but when we have a "flows", where we have to carry large session data between screens, things become very complicated. A web flow scope could be the perfect solution.
Dynamic reloading of classes without requiring a restart of the full web application. Theoretically, this should be possible unless a class is referred from the session. In practice, all containers restart the application when reloading a class. Hotswapping helps somewhat, but it's limited.
Facility for modular development of web applications. Currently, we either make a war for each module, or the full application is developed as a single war. Making a war for each module has many limitations, number one is a lack of application scope (a shared session scope between the wars). On the other hand, modular development in a single war is quite difficult when the development team is large. Someone already mentioned the lack of modularization support in JSPs.
Posted by: masum on January 07, 2006 at 07:34 AM
-
I'm using SipServlets, which is a perfect example of non-HTTP servlets. For more info on SIP and SipServlets check out this cool developer community site:
https://developer.ubiquitysoftware.com/products/folder.2006-02-11.0657029386/
Posted by: emmanuelproulx on May 30, 2006 at 11:42 AM
-
Don't know what the cons are, but regex for servlet mapping would be nice.
Posted by: cornichon on May 31, 2006 at 12:08 AM
-
Greg,
First of all thank your for starting this initiative.
It is highly needed and I think it is right time to start thinking about "re-inventing" the Servlets API.
It is one of the nicest, the most successful and the easiest to work with but it can be improved.
Before listing my specific suggestions let me say that among other things we should
look at some features of the Ruby language to get some ideas on how to simplify the web components.
Now to be specific.
Lets introduce the new concept called Web Aware object.
Web aware object is any java object that satisifes the method level contract.
It just needs to have one of the methods that match the HTTP methods:
public void onPost( HttpRequest request, HttpResponse response );
public onGet( HttpRequest request, HttpResponse response );
...
Then, in order to configure this component to respond to particular URL (e.g. http:///MyApplication/ProcessOrder )
it would have to be annotated with something like this:
@UrlMapping ProcessOrder
public void onGet( ... )
or as previosuly suggested bind that with @GetMethod
Absence of annotation would mean that component is not mapped
for processing of the URL based requests
(like not being mapped in web.xml)
and it would be treated as a regular java bean.
There would be no mandatory web.xml file.
Web.xml would be an option for some more complicated scenarios.
For the basic scenarios annotations would be sufficient
Why I am proposing this?
Because of the practical experience.
Once we define and map the servlets in web.xml we never touch that definition again.
Plus, web.xml is not configurtable on the fly. So why have the external xml for it.
We could have smarter application server tools that tell us which components we have
configured for web access instead of having it in an external xml.
Thank you,
Edmon Begoli
http://blogs.ittoolbox.com/eai/software
Posted by: ebegoli on May 31, 2006 at 05:49 AM
-
Hi Greg....Your first item - File Upload - gets my vote. The absence of this item is painful....it would be useful to about 20-30% of my web apps.
Posted by: johanley on June 22, 2006 at 05:36 PM
|
java.net RSS Feeds
