My favorites | Sign in
Project Logo
                
Search
for
Updated Aug 31, 2008 by dhanji
WarpServletMigration  
Details about future of warp-servlet

Currently, the source code is accessible at: http://code.google.com/p/warp-datagrid/source/browse/#svn/trunk/warp-servlet

It will almost certainly move from there when it finds a good home =)

What does warp-servlet do?

Integration

Conversations

Conversations are roughly based around issue #5 in the Guice tracker. They are designed as follows:

  • A simple scope which any key can be bound to
  • URLs are rewritten an ;wconvid=... addendum
  • This conv id is stripped from the URL prior to dispatch to the filter pipeline
  • Users should process emitted URLs using the Conversation.rewrite() utility
  • Conversations need to be explicitly started and ended using Conversation.begin() and .end()

Extensibility

Conversations can be persisted in a user-provided data store by creating custom impls for ConversationManager and ConversationContext. The former is the storage service that starts, retrieves and destroys convs. ConversationContext is a logical representation of a single conversation instance (unique by conv key).

RoadMap

These are things that should be improved before conversations are release-ready:

Lingering Design Questions

Finally

Do email me (dhanji@gmail.com) if you have any questions. Please post comments and suggestions on this page.


Comment by robbie.vanbrabant, Aug 31, 2008

There are a few other things on my wish list, as said in the Guice issue that tracks this integration effort (issue 239):

  • Support for multiple WS modules per injector: this is crucial for third party
extensions, for example my HttpInvoker port: http://code.google.com/p/garbagecollected/wiki/GuiceHttpInvoker
  • A revised DSL (optional). I don't like the filters() in:
Servlets.configure().filters().servlets().serve("*.html").with(MyServlet.class)

Besides that, I think we should also discuss timing. If we're going to align WS's release cycle with Guice's, then we should think about what we want to support and maybe cut features we intend to change. For example, we should probably also spend some time on Javadoc, perhaps some tests and an API review.


Sign in to add a comment
Hosted by Google Code