Hi there.
My application, along with the usual HTML pages generated with Wicket,
should also expose some RESTful services. These REST calls should return
documents of various types: images, movies, as well as RDF/XML and N3
and so far.
In an architectural spike I've made, I've used Jersey (implementation of
JSR-311) and of course the two things can co-exist; so everything works
and I don't have "technical" problems to solve (at the moment).
The dilemma is architectural: I'm guessing whether getting JSR-311 in
increases complexity in a way that can be avoided. In other words, could
Wicket be able to serve the same facilities provided by JSR-311 (I mean,
the subset I need)?
Actually, Wicket can serve non-HTML contents by means of
DynamicWebResource, so it seems doable. There are two specific questions
now:
1. Security. For HTML pages, protected areas shoud handle login in the
WIcket way (or what I assume is the normal Wicket way), i.e. rendering a
specific HTML login page. For other types of documents, instead, I need
HTTP authentication and perhaps in future some token-based approach. The
point is that in any case either I deny the access or I give the
resource, but I can't send back an HTML login page when the client
expects a different document type. Would I be able to handle this with
Wicket?
2. Having the same URL delivering different contents according to the
Accept header. For instance, http://foo.bar/blah should normally render
an HTML page; but if a Accept: text/n3 header is specified, a N3 should
be returned. This means that in the former case the default Wicket
workflow would be ok; in the latter, a DynamicWebResource should be
provided. I think I can solve this using JSR-311: I could implement a
super-filter that discriminates on the presence of the Accept: header
and dispatches either to the Wicket or to the Jersey filter (of course I
would implement a custom URL mount scheme so Wicket accepts the same URL
as Jersey).
Hints? I'm searching to find ASAP a reason for deciding to keep Jersey
or to get rid of it, so I can go on with the development without too
many fears of having to change something in future.
Thanks.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
