Seeing the new features in Servlet API 2.5, the feature I most needed, regular expression matching, was missing. Regular expressions are in JDK 1.4 and above (Servlet 2.5 requires JDK 1.5), so its pretty amazing that a basic feature like this is missing. Certainly, there's a long history of using regexp to map paths, as built into Apache (especially mod_rewrite).
I was really hoping for this feature, to support even friendlier URLs.
Other features I'd like to see:
- Proper notifications about session synchronization events --- I want to know when an object is being de-serialized from another server in the cluster so I can set up some necessary ThreadLocals
- Programatic login, and the ability to provide an application-specific login page --- I want to be able to use Tapestry's superior form support to manage logins
- Failover notification --- I think servlets should support clustering without sharing data, but providing a notification when a failover has occured. Data could be stored in the HttpSession, but would not be replicated. This would give a good middle-ground between single-server and enterprise cluster.
- Servlet meta-data access --- servlets should be able to find out about their URL patterns and filters
I probably could go on ... I've been working around the Servlet API for quite some time.
Meanwhile, there are some improvements. The DTDs have been simplified (allowing multiple URL patterns per servlet is a step in the right direction --- how about allowing the mapping right inside the <servlet> itself?) The new annotation support looks quite nice ... in fact, putting annotations on fields instead of on methods is the (long term) way to get Tapestry away from using abstract classes, and I can almost smell the bytecode enhancement in the approach implied by the @Resource annotation.
9 comments:
I don't see why @Resource would require bytecode processing.
The annotation is on a field. There may or may not be a setter method for that field. This implies that the field's value is being set via a constructor ... but not one you write. This implies that the bytecode of your class is being modified, to provide the setter method, or a constructor. Unless they went the cheesey route, and required that the field be public.
It seems silly to expose the shortcomings of the new servlet specification after it has been through the whole review process.
There have been public review copies available since 26 Feb, 2004
Get involved! ;-)
heh heh.
What the hell is "heh heh."?
I actually provided this feedback to Ed Burns who did pass it on to the group.
It should not be necessary to be on the group to get common-sense changes made to the spec. But I'll keep my eyes open for the 2.6 spec ... in my spare time :-).
You can hook deserialization by implementing a readObject() method.
readObject() is quite insufficient for my purposes; this is about HiveMind and hooking serialized proxies back into the Registry ... and, of course, there may be more than one Registry, so you can't base this on a static field, either. Worse, you can't even base it on a customized ObjectInputStream, since the servlet container, not your code, creates the stream. So I rely on ThreadLocal wrapper around a WeakReference, but I'm not 100% sure it will work, because there's no guarantee the right Registry instance will have been stored into the ThreadLocal before the service proxies are deserialized. This is what I get for writing a framework and not a server, where I would have control over that stuff :-)
Howard, wouldn't a Servlet Listener implementing javax.servlet.http.HttpSessionActivationListener be enought? This would give you sessionWillPassivate() and sessionDidActivate() hooks.
Yes, it requires one more line in web.xml, but it is worth it IMHO.
My opinion is the bind a servlet to "/" and be done with it. Then you are free to do whatever. The whole servlet thing is a mess.
"January 2006: Where's Tapestry 4.0 Final?" should be the question :D
now seriously: wouldnt it be better to bind tapestry to / like anonymous said before ? - why not let tapestry itself decide... this means we also could have different ways for handling images, special deeplinks etc as they could all be defined within the java part !
And another Question: When will Tapestry support SSL native ? - i mean, we have the way of using direct-link to send the visitor to a page over SSL but this still means that this page is not yet protected for non SSL calls - otherweise we could define in the .page file sth. like SSL=TRue that is must be access over an encrypted connection, else it would send a redirect to the encrypted page... would be really blazing and boosting security as well...
just a small thought,
regards
K
Post a Comment