Multiple applications
Dear all, is it possible to define multiple applications in a web.xml, each one attached to a servlet rooted at a different base URI? Apparently it's not possible because the application class is defined as a context parameter not linked to a servlet, but maybe I am missing something. Thank you for your help. Fabio -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1592443
Re: Multiple applications
You probably want to declare your application - url mapping in some configuration files outside of the code. If you're talking about web.xml file only, it seems you can't. 1) But you can use custom component (restlet.xml) http://www.restlet.org/documentation/1.1/ext/com/noelios/restlet/ext/servlet/ServerServlet.html http://www.restlet.org/documentation/1.1/api/org/restlet/Component.html 2) or you can specify these mapping in init / context parameters for your custom application, and make application be a Router, that will do in createRoot () initialization for ( param : init param list) this.attach(param.url, param.application). On Wed, Apr 8, 2009 at 11:06 AM, Fabio Mancinelli fabio.mancine...@gmail.com wrote: Dear all, is it possible to define multiple applications in a web.xml, each one attached to a servlet rooted at a different base URI? Apparently it's not possible because the application class is defined as a context parameter not linked to a servlet, but maybe I am missing something. Thank you for your help. Fabio -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1592443 -- Best regards, ~ Xasima Xirohata ~ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1592755
RE: Re: Multiple applications
You probably want to declare your application - url mapping in some configuration files outside of the code. If you're talking about web.xml file only, it seems you can't. Actually I was talking about web.xml file only. Thank you for your hints about solving the problem. Regards, Fabio -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1592971
RE: ServerResource conditional mode
Hi Dave,
As I just explained in reply to Tal, your initial issue with POST is now
addressed in SVN trunk. Hope this makes sense now what conditional
processing is for.
Regarding the support for annotations directly in ServerResource, I
initially thought about separating them, but felt that it would be nice to
be able to mix both approaches in some cases. In is also easier for somebody
to port his existing pre-1.2 resources to the new API and progressively
leverage annotations.
This isn't fixed in stone though and we have time for refactoring before 1.2
RC. Regarding the lack of documentation and explanation, this is mainly due
to the fact that this is still work in progress and the design isn't final
yet. The goal of Restlet 1.2 M2 was to get some early feed-back from the
community to adjust what needs to be.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : David Fogel [mailto:carrotsa...@gmail.com]
Envoyé : vendredi 3 avril 2009 07:27
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode
Hi Tal-
I've been struggling with that very question, as I, too had trouble with
POSTing to my new ServerResource subclass.
I also noticed that getPreferredVariant(Method.GET) is called during
processing of the POST request, and I couldn't figure out why.
At first I thought that was the cause of my problems, but it turned out that
my problem was in the 2nd time through getPreferredVariant(), in
doNegotiatedHandle(), this time called with (the correct) Method.POST. This
method was always returning a 406 status - CLIENT_ERROR_NOT_ACCEPTABLE.
my post method looked something like this:
@Post
public void postSomeData(Representation entity) throws ResourceException {
}
the getPreferredVariant code checks the Java return-type of the annotated
method, and in this case having a void return type meant that
getPreferredVariant returns null, which causes the doNegotiatedHandle to
return 406.
This doesn't seem like quite the right thing, since it's not clear to me
exactly what kind of content negotation can really usefully go on in the
(fairly common) case of a POST method which processes Form data and then
returns 204- success-no-content. It's also not clear to me whether I should
have given the @Post a mediatype value- should this be the incoming
representation type of form-url-encoded, or something else? not sure at
all.
I'd love to see some greater amount of docs or general explanation of what
the thinking is here, or else I fear this will cause significant confusion
for people... I found it particularly confusing how ServerResource combines
support for both annotated and non-annotated subclasses. Maybe support for
these two approaches should be broken out into two classes?
-Dave Fogel
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15288
27
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1593013
Re: 1.1.4 isn't in maven.restlet.org
Hello Mark, not at all, this is not a manual process. As written here [1], the public repository is updated twice a month on the 1st and the 15th of april. best regards, Thierry Boileau [1] http://www.restlet.org/downloads/maven Hi all, Any reason why restlet 1.1.4 isn't available in the maven.restlet.org repository yet? I assume its a manual deployment process? ...and then Buffy staked Edward. The End. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1584133 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1593014
RE: Use a proxy server with a Client?
Hi Shingo, Thanks for this suggestion. I've added a link to your email in the related RFE: Add parameters for proxies in HTTP clients http://restlet.tigris.org/issues/show_bug.cgi?id=317 Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Shingo Omura [mailto:omura_shi...@ogis-ri.co.jp] Envoyé : lundi 6 avril 2009 07:14 À : discuss@restlet.tigris.org Objet : Re: Use a proxy server with a Client? Hi, all. My name is Shingo Omura, newbie for restlet. Avi Flax wrote on 2008-06-12 23:49:07 PDT: A method like void setUseProxy(String host, int port) would make sense to me. I agree with that. So, I modify the source of org.restlet.Client so that Client can have void setProxy(String host, String port) and can access through proxy server. I send a patch file and the original Client.java (attached). Best Regards, -- Shingo Omura omura_shi...@ogis-ri.co.jp OGIS-RI, CO., LTD. Rob, thank you for the thorough and informative answer! I really appreciate it. The system properties approach for the Net connector will suffice for me for now, but I really think this ought to be available via the Client API. A method like void setUseProxy(String host, int port) would make sense to me. Thanks again! Avi On Thu, Jun 12, 2008 at 10:54 PM, Rob Heittman rob.heitt...@solertium.com wrote: Thara S had an open question about this in another thread. I think the answer is here: http://restlet.tigris.org/issues/show_bug.cgi?id=317 For the Net connector you ought to be able to use the common idiom of setting the system properties http.proxyHost and http.proxyPort. This idiom does not work with the Apache HttpClient connector anyway. Steve Loughran went to big lengths to fix this here: http://jira.smartfrog.org/jira/browse/SFOS-629 and he also contributed some ideas to the bug report. I'd rather set properties on the client context, like configuring server properties, though ... If enough people think this is a big deal, I'm happy to propose a patch and see if Jerome's willing to bump it earlier. - R On Thu, Jun 12, 2008 at 6:55 PM, Avi Flax a...@arc90.com wrote: Hi all, does anyone know of a way to have a Client use a proxy server when making a request? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15584 31 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1593795
RE: DirectoryResource throws/logs useless exceptions for CLAP protocol
Dave, Thanks for looking at the details on Directory implementation. This are certainly opportunities to refactor and optimize this class. As you found out, it is handling pretty complex stuff. We would welcome some contributions in this area. We have also received a report regarding performance issue of Directory used with the WAR client that we need to inspect. This might be due to the same reason: Improve performance of WAR client http://restlet.tigris.org/issues/show_bug.cgi?id=736 Regarding the production ready status, we have been using this class on all our Web sites with no trouble so far. Would you mind creating a bug report for what you found? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com _ De : Rob Heittman [mailto:rob.heitt...@solertium.com] Envoyé : mardi 7 avril 2009 14:26 À : discuss@restlet.tigris.org Objet : Re: DirectoryResource throws/logs useless exceptions for CLAP protocol I also wish it were a bit faster. We do serve several hundred thousand impressions out of Directory every month, but we serve several million using thinner Resources not wrapped in Directory -- not sure what would happen if we wrapped those in Directory. On Tue, Apr 7, 2009 at 1:58 AM, David Fogel carrotsa...@gmail.com wrote: The Directory class is the only built-in way for plain, non-servlet, Restlet apps to serve static content. Should we consider it production-ready w.r.t. performance under load? Another way of asking this: is the Directory class a reasonable substitute for, e.g. Jetty's DefaultServlet? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1593889
RE: Grizzly Https Server
Hi Sheshakiran, Regarding the HTTPS configuration of our Grizzly connector, you can check this page: http://www.restlet.org/documentation/1.2/ext/org/restlet/ext/grizzly/HttpsSe rverHelper.html Regarding BASIC authentication, it will work fine as well (nothing specific to Grizzly connector here, just regular Restlet stuff). Regarding asynchronicity, I'm not sure what you mean. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : srsk [mailto:sheshakira...@gmail.com] Envoyé : mardi 7 avril 2009 16:25 À : discuss@restlet.tigris.org Objet : Grizzly Https Server Hi, I am Sheshakiran, developer from one of the service based industry. I have a requirement to develop one Grizzly Asynhcronous Https Server, which would do Basic Authentication and HTTPCertificate validation. I found Http implementation of grizzly server, but i am not able to get sufficient information on Grizzly Https implementation. Any kind of help would be really appreciable. Https should accept inputs like 1) Username and Password and 2) Certificate details like i) Keystore ii) Trusted certificate iii) passwords for keystore and certificate iv) private key alias and private key password ... thanks .. Sheshakiran -- View this message in context: http://n2.nabble.com/Grizzly-Https-Server-tp2599248p2599248.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15779 17 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1593977
RE: Re: Media types specified as a query parameter
Hi Fabio, As JaxRsApplication is a subclass of org.restlet.Application, there is no reason for the tunnel service not to work properly. The default query param to override the accepted mediatypes is media as documented here: http://www.restlet.org/documentation/snapshot/api/org/restlet/service/Tunnel Service.html Actually, I've tested your sample code and the following URI triggers that tunnel service: http://localhost:8182/users/toto?media=xml You can check that it works by looking at the logs, in my case: INFO: 2009-04-0812:28:30127.0.0.1 - - 8182 GET /users/toto - 404 ... Note that the URI can cut to remove the query parameter to make sure that this mechanism is transparent to your resources. You might have other issues down the road in your resource maybe. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Fabio Mancinelli [mailto:fabio.mancine...@gmail.com] Envoyé : mardi 7 avril 2009 17:08 À : discuss@restlet.tigris.org Objet : RE: Re: Media types specified as a query parameter I am starting to think that the ?media mechanism is not supported when using the JAX-RS extension. This is probably the reason... Anyway I did this very simple application http://pastebin.com/m5e963eea Could somebody confirm the incompatibility, or hint a solution if I am doing something wrong? :) Thanks, Fabio -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15783 57 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1594228
Re: 1.1.4 isn't in maven.restlet.org
Hi Mark, it will be available on 15/4. Check this: http://www.restlet.org/downloads/maven. The first one is freely accessible from http://maven.restlet.org and contains all Restlet JARs and third party dependencies that aren't available in the main public Maven repository. It will be automatically refreshed on the 1st and on the 15th of each month. Best Regards, Davide Angelocola On Tue, Apr 7, 2009 at 11:54 PM, Mark Derricutt m...@talios.com wrote: Hi all, Any reason why restlet 1.1.4 isn't available in the maven.restlet.org repository yet? I assume its a manual deployment process? ...and then Buffy staked Edward. The End. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1584133 -- -- Davide Angelocola -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1592423
Weird issue with VirtualHosts
Hi, I'm trying to setup a couple of virtual hosts following the example given for the actual restlet website. My code looks like this: // // www.mywebsite.com // VirtualHost host = new VirtualHost(getContext()); host.setHostDomain(www.mywebsite.com| + ipAddress); host.setHostPort(80| + Integer.toString(port)); host.attach(new WwwMywebsiteCom(wwwUri + /html)); getHosts().add(host); // // media.mywebsite.com // host = new VirtualHost(getContext()); host.setHostDomain(media.appliedobjects.com); host.setHostPort(80| + Integer.toString(port)); host.attach(new MediaMywebsiteCom(wwwUri + /media)); getHosts().add(host); The funny thing is when I run this code locally on my own machine the media.mywebsite.com works fine. But when I install the jar on the production server and attempt to run in there the media virtual host doesn't seem to work. In fact no requests are ever logged. Do you have any suggestions as to what I might be doing wrong? I've tried various combinations of values for the host domain and ports but to no avail. Thanks in advance, Matt -- View this message in context: http://n2.nabble.com/Weird-issue-with-VirtualHosts-tp2603116p2603116.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1589436
RE: Spring + Restlet 1.2-SNAPSHOT, NullPointerException
Thanks for the resources, Jerome. I'll take a look and see what I can learn from them! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=151
Re: ServerResource is currently incompatible with OSGi
Why involve Context at all? The AnnotationInfo associated with a Class?
extends UniformResource does not depend on Context. You could just add a
method to AnnotationUtils:
public static AnnotationInfo getAnnotationDescriptor(Class?
extends UniformResource resourceClass) {
AnnotationInfo result = cache.get(resourceClass);
if (result == null) {
result = computeAnnotationDescriptor(resourceClass); // use code
from existing getAnnotationDescriptors for this
AnnotationInfo prev = cache.putIfAbsent(resourceClass, result);
if (prev != null) result = prev;
}
return result;
}
private static final ConcurrentMapClass? extends Resource,
AnnotationInfo cache =
new ConcurrentHashMapClass? extends Resource, AnnotationInfo();
Then you don't need getAnnotationDescriptors. You probably want a way to
clear cache entries if a class is reloaded, say.
You could get more fancy, with Futures and such, but I think that would be
wasted effort.
--tim
On Tue, Apr 7, 2009 at 1:20 PM, Tal Liron tal.li...@threecrickets.comwrote:
Ah, I can see your point now.
I would recommend, then, that a Context would have two separate
ConcurrentHashMaps, something like this:
1. Context.getConfiguration() -- this would be for the user
2. Context.getImplementationCache() -- this would be for things like
AnnotationUtils, and the user should not normally look at this, except
perhaps for debugging
-Tal
David Fogel wrote:
Hi Tal-
I think what you suggested about appending a classloader id (perhaps
System.identityHashCode(cl) ?) would work.
Regarding the Restlet Context and this cache being cruft: You say
the Context is a reasonable place for information that applies to the
Application, but this doesn't have annotation cache doesn't have
anything to do with my Application, it's related to a hidden
_implementation_ detail. As an end-user, we're not meant to be using
this annotion info cache directly. Yet the Context, as a very
prominent and unavoidable part of the Restlet public API is meant to
be used and understood. That's why I think it isn't a good place to
stash implementation-related data like this annotation stuff.
-Dave
--http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1572499
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1584755
RE: access control
Hi Helen, If you are in Restlet 1.1, I would suggest writing a simple Filter subclass and to override the beforeHandle() method. Check the IP address and if you want to block it, set the status to Status.CLIENT_ERROR_FORBIDDEN. This will be simpler than extending Guard. In Restlet 1.2, the new security API is more flexible and I would suggest to extend the Authorizer class/filter instead. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : helen chen [mailto:hc...@aip.org] Envoyé : vendredi 3 avril 2009 03:00 À : discuss@restlet.tigris.org Objet : Re: access control I'm reading the document about the Guard. It looks like when creating a Guard, I can specify ChallengeScheme.CUSTOM which can be used for IP address check. But if I do it, then when should I check the IP address? Does that mean I have to create a sub class of Guard, override method authenticate() and authorize()? Does anyone have ever done this? Is there any sample code I can take a look? since only server side it check IP address, at client side, I guess I don't need to do request.setChallengeResponse() for the ChallengeSchema.CUSTOM right? I would appreciate if anyone has any ideasabout how to deal with it . helen Helen Chen 04/02/09 5:09 PM Hello there, I'm having a situation like the following: I need to restrict that only one ip adddress is allowed to access to a specific uri that is developed by restlet. And other pages are open to all. I know this usually should be done at the web server part. But if I need to do it through Restlet, Can I use Guard to do it? If yes, does anyone have example? Thanks, Helen -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1593480
Re: Comments on First Resource article (Restlet 1.2m2)
Great. One more thing -- the code in ItemResource should also use the return
value of putIfAbsent to decide whether the item was created or updated:
@Put
public void storeItem(Representation entity) throws IOException {
// The PUT request updates or creates the resource.
if (item == null) {
item = new Item(itemName);
}
// Update the description.
Form form = new Form(entity);
item.setDescription(form.getFirstValue(description));
// Update the item in the list.
if (getItems().putIfAbsent(item.getName(), item) == null) {
setStatus(Status.SUCCESS_CREATED);
} else {
setStatus(Status.SUCCESS_OK);
}
}
On Tue, Apr 7, 2009 at 3:45 AM, Thierry Boileau thierry.boil...@noelios.com
wrote:
Hi Tim,
thanks a lot for your useful comments!
Ive updated the sample code.
The call to putIfAbsent needs to be prefixed with getItems().
Actually, I created a putIfAbsent method on the BaseResource class
because I was not aware you meant to use a ConcurrentMap.
best regards,
Thierry Boileau
Great, thanks! Just a few more tweaks:
The type of the items field in FirstResourceApplication and the return
type of getItems() in FirstResourceApplication and BaseResource should
be ConcurrentMap, in order to have access to the putIfAbsent method.
There's no need to repeat the construction of ConcurrentHashMap in the
two constructor bodies -- it only raises the question of why it was
written that way. Better to initialize at the declaration point and
keep the constructors simple:
ItemsResource could be simplified by removing the CollectionItem
items field and the doInit method and simply using getItem().values()
in the for loop in the @Get method. You already have a more
substantive example of using doInit in ItemResource.
private final ConcurrentMapString, Item items
= new ConcurrentHashMapString, Item();
public FirstResourceApplication(Context context) { super(context); }
public FirstResourceApplication() {}
The sentence immediately preceding the FirstResourceApplication code,
That's why you will notice that the map of items is made final and is
an instance of the ConcurrentHashMap class. should probably be
something like That's why you will notice that the map of items is a
final reference to a ConcurrentMap, rather than a plain Map. The
concrete type, ConcurrentHashMap, is not the point -- it could be any
implementation of ConcurrentMap, e.g., something produced by Google
Collections' MapMaker.
The call to putIfAbsent needs to be prefixed with getItems().
--tim
On Mon, Apr 6, 2009 at 5:09 AM, Thierry Boileau
thierry.boil...@noelios.com mailto:thierry.boil...@noelios.com
wrote:
Hi Tim,
thanks a lot for your comments! The sample code has been updated.
best regards,
Thierry Boileau
The introduction has ...which means that you don't need to take
care
of thread-safe concerns. which should be thread-safety
concerns.
This might still be a little strong, as you still have to worry
about
thread-safety in all the objects that your Resources refer to
that are
shared between threads. You could say that you don't need to
make your
resource subclasses thread-safe, but that sounds anticlimactic.
That's why you will notice that the map of items is made immutable
and is an instance of the ConcurrentHashMap class. You mean
final,
not immutable. In actual practice, you'd really want to make the
items field a ConcurrentMap rather than just Map, because the @Post
and @Put methods defined below would then be able to use
putIfAbsent
to avoid races. I know you want to keep the example simple, but I'd
hate for readers to draw the conclusion that they don't have to
worry
about races:
// Register the new item if one is not already registered.
if (!getItems().containsKey(itemName)
getItems().putIfAbsent(itemName, new Item(itemName,
itemDescription)) == null) {
// Set the response's status and entity
setStatus(Status.SUCCESS_CREATED);
Representation rep = new StringRepresentation(Item
created,
MediaType.TEXT_PLAIN);
// Indicates where is located the new resource.
rep.setIdentifier(getRequest().getResourceRef().getIdentifier()
+ / + itemName);
result = rep;
} else { // Item is already registered.
setStatus(Status.CLIENT_ERROR_NOT_FOUND);
result = generateErrorRepresentation(Item + itemName
+ already exists., 1);
}
The business about setModifiable is obsolete, right? You get it for
free by defining a method annotated
Re: Restlet and maven
Bruno Harbulot wrote: Rémi Dewitte wrote: Hello, I know there is some ongoing work about maven and restlet. If I checkout the trunk and build it, how do I install the new artifacts into my local m2 repository ? Assuming you're on a unix machine, I find the easiest to be: 1. Edit build/build.properties to set the maven option to 'true'. 2. cd build/dist/maven2/restlet-1.2snapshot 3. tar cf - . | tar xvf - ~/.m2/repository Sorry, I meant: tar cf - . | tar xvf - -C ~/.m2/repository -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1581688
Re: Restlet and maven
Rémi Dewitte wrote: Hello, I know there is some ongoing work about maven and restlet. If I checkout the trunk and build it, how do I install the new artifacts into my local m2 repository ? Assuming you're on a unix machine, I find the easiest to be: 1. Edit build/build.properties to set the maven option to 'true'. 2. cd build/dist/maven2/restlet-1.2snapshot 3. tar cf - . | tar xvf - ~/.m2/repository Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1578606
Re: Grizzly Https Server
Hi Sheshakiran, Are you looking for using Grizzly or Restlet with the Grizzly connector? In Restlet, SSL support has been harmonised using an SslContextFactory for all the connectors. It supports client-certificate authentication (provided your configure it with the trust store you require.) If it's for Grizzly only, I'd suggest posting to the Grizzly list. Coincidentally, I've just made a few suggestions for improvement in Grizzly, but these don't affect Restlet and its use of Grizzly. (Note that the default should work at least, that is, specifying the keystore/truststore using the usual javax.net.ssl.* system properties, in Grizzly and Restlet.) Best wishes, Bruno. srsk wrote: Hi, I am Sheshakiran, developer from one of the service based industry. I have a requirement to develop one Grizzly Asynhcronous Https Server, which would do Basic Authentication and HTTPCertificate validation. I found Http implementation of grizzly server, but i am not able to get sufficient information on Grizzly Https implementation. Any kind of help would be really appreciable. Https should accept inputs like 1) Username and Password and 2) Certificate details like i) Keystore ii) Trusted certificate iii) passwords for keystore and certificate iv) private key alias and private key password ... thanks .. Sheshakiran -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1578563
Re: Restlet and maven
Hi Rémi, assuming you've installed maven in the PATH you must run the following command in trunk/modules: mvn install using netbeans is even easier, just install the maven plugin and open the modules project. Then build the project. Best Regards, Davide Angelocola 2009/4/7 Rémi Dewitte r...@gide.net Hello, I know there is some ongoing work about maven and restlet. If I checkout the trunk and build it, how do I install the new artifacts into my local m2 repository ? Thanks, Rémi -- -- Davide Angelocola -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1578295
RE: [1.1.3] Tomcat + RestletFrameworkServlet mapping SpringBeanRouter to /
Paul,
The problem is that the URI without the trailing slash isn't equivalent to
the one with it. It's true that in many cases, people assume it is
equivalent but it doesn't have to.
Also, relative URIs can be expressed in the same way if the ends with a
slash or not, leading to further routing issues. The only way we found to
clean that is to force the client to redirect itself to the URI with a
slash. However, it isn't something we should do automatically.
BTW, there is a related RFE:
Improve matching of directory URIs
http://restlet.tigris.org/issues/show_bug.cgi?id=532
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
http://www.noelios.com
_
De : Paul Austin [mailto:mail-li...@revolsys.com]
Envoyé : mardi 7 avril 2009 21:58
À : discuss@restlet.tigris.org
Objet : Re: [1.1.3] Tomcat + RestletFrameworkServlet mapping
SpringBeanRouter to /
Here is a class which fixes the issue. Probably a better solution would be
to change the Route class so that if the remainingPart is it sets it to
/ before doing the regex matching. On a related note is it possible to
force exact matching so that say /apps would be mapped but not /apps/xyz?
public class RootSpringBeanRouter extends SpringBeanRouter {
@Override
public void handle(Request request, Response response) {
Reference resourceRef = request.getResourceRef();
if (resourceRef.getRemainingPart().equals()) {
resourceRef.addSegment();
}
super.handle(request, response);
}
}
On Tue, Apr 7, 2009 at 12:27 PM, Paul Austin mail-li...@revolsys.com
wrote:
In my project I am deploying an application as a war file. The root of the
web application /* is mapped to the RestletFrameworkServlet so that all
handling is performed by Restlet.
servlet
servlet-namebpf/servlet-name
servlet-classcom.noelios.restlet.ext.spring.RestletFrameworkServlet/servl
et-class
/servlet
servlet-mapping
servlet-namebpf/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
The root restlet is a SpringBeanRouter and I have a mapping for / to a
resource as shown below.
bean id=root class=org.restlet.ext.spring.SpringBeanRouter /
bean
name=/
id=rootResource
scope=prototype
class=myResourceClass
/
The war is deployed to /ws on my server.
If I access /ws I get an Restlet status page error saying The server has
not found anything matching the request URI but if I use /ws/ it works
correctly.
I tried mapping to to see if that would work and it gives the same
behaviour.
Is it possible to modify the router so that the root resource does not need
the trailing slash?
Cheers,
Paul
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1594914
RE: Weird issue with VirtualHosts
Hi Matt, Are you using some kind of reverse proxy or port mapping/firewall software in front of your Restlet component? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : MattyJ [mailto:mjwat...@gmail.com] Envoyé : mercredi 8 avril 2009 06:15 À : discuss@restlet.tigris.org Objet : Weird issue with VirtualHosts Hi, I'm trying to setup a couple of virtual hosts following the example given for the actual restlet website. My code looks like this: // // www.mywebsite.com // VirtualHost host = new VirtualHost(getContext()); host.setHostDomain(www.mywebsite.com| + ipAddress); host.setHostPort(80| + Integer.toString(port)); host.attach(new WwwMywebsiteCom(wwwUri + /html)); getHosts().add(host); // // media.mywebsite.com // host = new VirtualHost(getContext()); host.setHostDomain(media.appliedobjects.com); host.setHostPort(80| + Integer.toString(port)); host.attach(new MediaMywebsiteCom(wwwUri + /media)); getHosts().add(host); The funny thing is when I run this code locally on my own machine the media.mywebsite.com works fine. But when I install the jar on the production server and attempt to run in there the media virtual host doesn't seem to work. In fact no requests are ever logged. Do you have any suggestions as to what I might be doing wrong? I've tried various combinations of values for the host domain and ports but to no avail. Thanks in advance, Matt -- View this message in context: http://n2.nabble.com/Weird-issue-with-VirtualHosts-tp2603116p2603116.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15894 36 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1595002
Re: Spring + Restlet 1.2-SNAPSHOT, NullPointerException
Hi Jerome, There is a bug specifically with the SpringFinder class. The parent Finder was refactored such that it now checks to see that the targetClass property is an instance of Handler. Previous versions of the class did not depend on targetClass to be non-null. Since the SpringFinder only deals with the createResource() method, the targetClass property is always null. Eric, as a temporary workaround, you can create your own SpringFinder class that overrides getTargetClass() to always return Resource.class. Or you can set the targetClass property on all your SpringFinder instances. Kevin On Tue, Apr 7, 2009 at 1:35 PM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Eric, Here is a sample configuration attached. You can check the source code here: http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet.test/src/org/restlet/test/ext/spring/ Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -- *De :* Eric Hough [mailto:k2e...@gmail.com] *Envoyé :* vendredi 3 avril 2009 21:32 *À :* discuss@restlet.tigris.org *Objet :* Spring + Restlet 1.2-SNAPSHOT, NullPointerException I've been having trouble getting Spring to play nice with Restlet (I'm experienced with Spring, a newbie with Restlet, so please bear with me!). Using Spring 2.5.6 and Restlet 1.2-SNAPSHOT. I want to define a resource called uniq and map /uniq to my UniqResource bean (extends Resource). Simple, yeah? When I browse to http://localhost:8182/uniq, I get the following stack trace: Apr 3, 2009 10:54:19 AM org.restlet.engine.StatusFilter getStatus SEVERE: Unhandled exception or error intercepted java.lang.NullPointerException at java.lang.Class.isAssignableFrom(Native Method) at org.restlet.resource.Finder.handle(Finder.java:391) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:520) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:520) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:520) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.engine.StatusFilter.doHandle(StatusFilter.java:153) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:126) at org.restlet.Component.handle(Component.java:724) at org.restlet.Server.handle(Server.java:355) at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:149) at org.restlet.engine.http.StreamServerHelper$ConnectionHandler.run(StreamServerHelper.java:89) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Apr 3, 2009 10:54:19 AM org.restlet.engine.LogFilter afterHandle INFO: 2009-04-03 10:54:19 127.0.0.1 - - 8182 GET /uniq - 500 365 - 39 http://localhost:8182 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.10 (intrepid) Firefox/3.0.8 - Here's my applicationContext.xml: ?xml version=1.0 encoding=UTF-8? beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd; bean id=springComponent class=org.restlet.ext.spring.SpringComponent init-method=start destroy-method=stop property name=server bean class=org.restlet.ext.spring.SpringServer constructor-arg value=http / constructor-arg value=8182 / /bean /property property name=defaultTarget ref=springRouter / /bean bean id=springRouter class=org.restlet.ext.spring.SpringBeanRouter / bean name=/uniq autowire=byName id=uniqResource class=org.example.uniq.rest.UniqResource scope=prototype property name=nextUniqDao ref=nextUniqDao / /bean /beans And UniqResource.java: package org.example.uniq.rest; import java.io.StringReader; import org.example.uniq.dao.NextUniqDao; import org.restlet.data.MediaType; import org.restlet.data.Status; import org.restlet.representation.ReaderRepresentation; import org.restlet.representation.Representation; import
RE: JAXRS and media type via query parameters
Fabio, In addition to my other reply, I should mentioned that I was using Restlet 1.2 trunk for testing. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : webp...@tigris.org [mailto:webp...@tigris.org] Envoyé : mardi 7 avril 2009 10:38 À : discuss@restlet.tigris.org Objet : JAXRS and media type via query parameters Hi everybody, I am using the JAX-RS extension for developing my application. I would like to specify the accepted formats using query parameters because the client I am using is not able to send accept headers. I did this in the JaxRsApplication create root method: getTunnelService().setEnabled(true); getTunnelService().setExtensionsTunnel(true); getMetadataService().setEnabled(true); but requesting a URI using, for example, http:///resource?media=json (I also tried media=application/json, accept=application/json) doesn't work. Any hint? Thanks for your help. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15736 79 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1594927
RE: Multiple Application Handling in web.xml
Hi Tamer, The issue is with your restlet.xml file. The URI template shouldn't contain a * at then end: ?xml version=1.0? component xmlns=http://www.restlet.org/schemas/1.2/Component; server protocols=HTTP/ defaultHost attach uriPattern=/FirstResourceApplication/ targetClass=sample.reslet.applications.FirstResourceApplication / attach uriPattern=/FirstStepsApplication/ targetClass=sample.reslet.applications.FirstStepsApplication / /defaultHost /component Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com _ De : Tamer Abuelsaad [mailto:tamere...@gmail.com] Envoyé : mardi 7 avril 2009 03:49 À : discuss@restlet.tigris.org Objet : Multiple Application Handling in web.xml Hello, I am using restlet 1.2M2 in the TomCat 6 web container. I am trying to create multiple Restlet applications and define different URI patterns that map to each one. I tried to do this following all the Restlet examples posted and it seems that all the examples show how to handle only one application in the web.xml I found an example referring to restlet.xml and defining Components. I can't seem to get this to work. I am attaching my web.xml and restlet.xml and would truly appreciate it if someone can tell me why I am getting a 404 error when I try to access either of the following URLs: http://localhost:8080/SampleRest/FirstResourceApplication/items http://localhost:8080/SampleRest/FirstStepsApplication web.xml content: ?xml version=1.0 encoding=UTF-8? web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=http://java.sun.com/xml/ns/javaee; xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; id=WebApp_ID version=2.5 display-nameSampleRest/display-name !-- Restlet adapter -- servlet servlet-nameRestletServlet/servlet-name servlet-classorg.restlet.ext.servlet.ServerServlet/servlet-class /servlet !-- Catch all requests -- servlet-mapping servlet-nameRestletServlet/servlet-name url-pattern/*/url-pattern /servlet-mapping /web-app restlet.xml content: ?xml version=1.0? component xmlns=http://www.restlet.org/schemas/1.2/Component; server protocols=HTTP/ defaultHost attach uriPattern=/FirstResourceApplication/* targetClass=sample.reslet.applications.FirstResourceApplication / attach uriPattern=/FirstStepsApplication/* targetClass=sample.reslet.applications.FirstStepsApplication / /defaultHost /component Thank you -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1593813
RE: Easy way to serve static content
Hi Paul,
Thanks for this feed-back. This aspect wasn't clear at all looking at the
Javadocs of the Servlet extension. So, I have just added some explanations
in ServerServlet and also moved many implementation classes into an
org.restlet.ext.servlet.internal package that is hidden from public
Javadocs. You shouldn't attempt to instantiate the WarClient class manually.
In your case, you should just use the WAR client, automatically available,
in your resources:
getContext().getClientDistpatcher().get(war:///WEB-INF/web.xml);
Hope this helps.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com/
http://www.noelios.com
_
De : Paul Austin [mailto:mail-li...@revolsys.com]
Envoyé : lundi 6 avril 2009 16:56
À : discuss@restlet.tigris.org
Objet : Easy way to serve static content
Is there an easy way to configure the SpringBeanRouter to use files within a
war file? For example /css would be mapped to /css/* resources within the
war file.
I was trying the following but I could not get hold of the ServletContext
public class StaticWarResource extends Resource {
private static final ListVariant VARIANTS = Arrays.asList(new
Variant(MediaType.ALL));
public StaticWarResource() {
setVariants(VARIANTS);
}
@Override
public Representation represent(Variant variant) throws ResourceException {
ServletContextAdapter context = (ServletContextAdapter)getContext();
ServletContext servletContext = context.getServletContext();
MediaType mediaType = variant.getMediaType();
Request request = getRequest();
Reference reference = request.getResourceRef();
String path = reference.getRelativePart(true);
ServletWarEntity entity = new ServletWarEntity(servletContext, path);
return entity.getRepresentation(mediaType, 1);
}
}
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1593742
RE: ServerResource conditional mode
Hi all,
Let me try to reply to the rest on this thread in one mail.
1) Multiple POST/PUT methods for different types of request entity
It will be possible to specify the media type of the entity passed to POST
and PUT methods in the annotation value, in addition to specifying the
optional media type of the returned entity.
Again, you can find a bit more details in the specifications page (see
Annotations parameter paragraph):
http://wiki.restlet.org/developers/172-restlet/226-restlet.html
There are examples given:
@Get(xml) : Returns a representation in the text/xml media type
String toString();
@Put(xml) : Stores representations in the text/xml media type after
conversion to a DOM document
void store(Document doc)
@Put(text:xml) : Stores representations in the text/xml media type after
conversion to a DOM document and returns a plain text response
String store(Document doc)
This isn't implemented yet, this is the next step for 1.2 M3.
2) Exceptions caught
Currently (SVN trunk at least), the ResourceExceptions are caught and the
response status is updated accordingly. This is done in the
ServerResource#handle() method. Other exceptions will be caught upper in the
processing chain, by the StatusService for example.
We do have some plans to extend the ConverterService in order to
automatically convert common exceptions into matching statuses, but I'm not
clear yet whether this is such a good idea (JAX-RS has this).
3) Variants declaration
Currently, there is a modifiable map (MapMethod, Object) that is used to
declare variants for either all methods or specific ones. We are considering
adding a new VariantDescriptor class that would allow to express more
complex ranges of variants like saying I accept all variants with a media
type in this set (XML or JSON or Atom or ...) and a language in this set.
This would be much more efficient that listing all the combinations
possible.
4) Method that don't return anything
For methods like POST that don't have to return an entity, it is possible to
annotate a Java method with just @Get as an annotation, and no value.
Depending on the input parameter of the method, the ServerResource should
invoke the proper method. It will also be possible to specify the accepted
variants with the following syntax:
@Post(:xml)
public void acceptXml(String value);
This could be simplified to this when no return type is present (:
optional)
@Post(xml)
public void acceptXml(String value);
If the method has a return type, then this should be written:
@Post(xml:xml)
public String acceptXml(String value);
@Post(json:json)
public String acceptJson(String value);
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com/
http://www.noelios.com
_
De : Tal Liron [mailto:tal.li...@threecrickets.com]
Envoyé : vendredi 3 avril 2009 09:46
À : discuss@restlet.tigris.org
Objet : Re: ServerResource conditional mode
You don't need to put a media type if you're using void (although, you could
potentially have more than one @Post handler, for several media types, to be
used depending on the expectation of a media type from the client...).
But, you do need to disable conditional mode:
@Post
public void handlePost(Representation rep) { ... }
@Override
protected void init()
{
setConditional(false);
}
Why? I'm still a bit in the dark about this. My current instinct tells me
that there's a bug in how the preferred variant is calculated for
conditional mode, in that it doesn't gather variants for the particular
method. Thus, I suspect (I haven't tested this) that if you had a @Get with
a particular media type (say, @Get(txt)) then there would be a preferred
variant and your @Post would be called, even in conditional mode.
Please take that last paragraph with a truckload of salt. :)
-Tal
David Fogel wrote:
Hi Tal-
I will definitely take a look at your script extension, thanks for the
suggestion!
I think I understand the general deal with the mediatype annotation
argument. But like I said, I was trying to define a Post method that
doesn't return content (and which therefore wouldn't make sense to
declare a mediatype for. So what's the right annotation argument for
this method?
@Post([what goes here?])
public void handlePost(Representation rep) { ... }
what I found was that I had to put a return type or a mediatype, or
else ServerResource refuses to call the method, due to the lack of a
preferredVariant.
-Dave
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1529
543 dsMessageId=1529543
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1593276
How to Fetch Request XML in Java Restlet
Hi, I'm trying to use java restlet. I'll be getting the input in the XML format I need to store the data in database return back the response back in XML format. Does any one have sample code which accepts input in XML then stores in DB returns response in XML? How to fetch the request in XML format in Java restlet? I'll really appreciate if some one can elaborate in detail!! Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1586179
RE: Resource factories
Hi Kyrre, I would be interested to read more about the other resource patterns that you found. We might want in the future to support some of them in Restlet directly. We packages reorganization in Restlet 1.2, we have more room for this. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Kyrre Kristiansen [mailto:kyrre_kristian...@yahoo.co.uk] Envoyé : mardi 7 avril 2009 16:28 À : discuss@restlet.tigris.org Objet : RE: Resource factories Hello, all. *rant alert* I came over this discussion, and wanted to share my experiences with creating resources. I started playing around with restlet before it became 1.0, and am generally very, very pleased with it. One of the things I use it for is my own prototype environment, where I can throw together some quite impressive applications in a matter of hours.. After creating a whole host of different resource types, I started seeing some quite distinct patterns in my resources, at least the simplest ones. This resulted in using Generics on my resources, where I created a class, ListResourceT extends Referrable (where Referrable is an interface, with one method, getId() ). I already have a generic DAO implementation based on the Referrable interface. In addition, I created a ResourceConfigT extends Referrable that I could pull off all the things I need for the ListResource (including the DAO, that's why it's parametrized), as well as a FormBuilderT extends BaseObject interface for building my objects based on a Form. All this leads to ListResource being a concrete class that relies solely on one object, the config, and that works with any resource that represents a Referrable subtype and is a top-level list resource. This, however, is where my trouble starts. Because at run-time, the system cannot differentiate between a ListResourceFoo.class and a ListResourceBar.class due to type erasure. At the moment I have to subclass ListResource for each type I am using it for, but hopefully making a parametrized Finder class that can then be attached to a Router, will solve my troubles. Has anyonw tried this? I have, BTW, also a solution for SingleResourceT extends Referrable, but this is not used as much as my ListResource, so I didn't describe this. The big, unsolved task is to make the resources and interfaces available for more complex resource hierarchies where you have to check for the existence of a parent resource before you allow creation and modification of a child resource. Twenty or so more resource types under the belt, and I might get there ;-) *end rant* Kyrre Kristiansen --- On Thu, 26/3/09, Jerome Louvel jerome.lou...@noelios.com wrote: From: Jerome Louvel jerome.lou...@noelios.com Subject: RE: Resource factories To: discuss@restlet.tigris.org Date: Thursday, 26 March, 2009, 1:20 PM Hi all, I've just found time to read this thread and enjoyed it very much. It's hard to find the best balance between so much points of views and ways to deal with instantiations, wiring of objects, etc. so it's nice to hear that the current design has more advantages than drawbacks. As Tal mentioned, we are redesigning the Resource API to support client-side resources and focused use of annotations. I didn't intend to change the way resources are instantiated though. But, if we can adjust the new design to accommodate more use cases, I would be interested to explore. Currently, we are working on Restlet 1.2 M2 which will give you a chance to play with the new resource API and provide feed-back. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com De : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : jeudi 26 mars 2009 08:49 À : discuss@restlet.tigris.org Objet : Re: Resource factories Thanks to all who replied on this. After a discussion on the code list, it became clear that the Restlety solution to configuring resources is to use the Context. The Context has a ConcurrentMap of attributes, described as so: This is a convenient mean[s] to provide common objects to all the Restlets and Resources composing an Application. So, that's it! The nice thing about contexts, too, is that they pass through restlets along the way. So, even if you configure your Application context in a certain way, you can apply filters or whatnot along the way to adapt the configuration. For example, a DebuggingFilter might enable all the configuration aspects that have to do with debugging. It's then easy to add/remove such a filter, even on-the-fly, without reconfiguring the whole application. -Tal
Re: Upload to Directory
Hi Christian,
I use the following restlet to save ANY uploaded file with whatever extension
or format it is ... hope it worx n solves your problem my friend
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package resources;
/**
*
* @author M.Abdel-Aziz
*/
import org.restlet.resource.Resource;
import org.restlet.Context;
import org.restlet.data.MediaType;
import org.restlet.data.Request;
import org.restlet.data.Response;
import org.restlet.resource.Representation;
import org.restlet.resource.StringRepresentation;
import org.restlet.resource.Variant;
import java.sql.*;
import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.FileUploadException;
import java.io.*;
import java.util.Calendar;
import java.util.*;
import cdf.capabilities.common.*;
import org.apache.commons.fileupload.FileItemFactory;
import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.restlet.ext.fileupload.RestletFileUpload;
public class FileUploader extends Resource {
String dateRequested = null;
public FileUploader(Context context, Request request,
Response response) {
super(context, request, response);
// Allow modifications of this resource via POST requests
setModifiable(true);
getVariants().add(new Variant(MediaType.MULTIPART_ALL));
}
@Override
public void handleGet() {
Representation rep = new StringRepresentation(invoke me with POST to
upload your file, MediaType.TEXT_PLAIN);
getResponse().setEntity(rep);
}
@Override
public void acceptRepresentation(Representation entity) {
try {
uploadFile(entity, requesterIP);
}
catch (IOException ioex) {
System.out.println(Oops...IOException !!!);
}
}
public void uploadFile(Representation file, String reqIp) throws
IOException {
FileItemFactory factory = new DiskFileItemFactory();
RestletFileUpload fileUpload = new RestletFileUpload(factory);
List list = null;
try {
list = fileUpload.parseRepresentation(file);
} catch (FileUploadException ex) {
System.out.println(Oops...FileUploadException !!!);
}
Iterator iter = list.iterator();
String fileName = null;
String destination = null;
if (iter.hasNext()) {
try {
FileItem item = (FileItem) iter.next();
if (!item.isFormField()) {
String uploadedFileName = item.getName();
File itemFile = new File(uploadedFileName);
// creating destination directory on the server
File destDir = new File(target_folder_here);
if (!destDir.exists()) {
destDir.mkdirs();
}
fileName = itemFile.getName();
destination = destDir.getAbsolutePath();
File destFile = new File(destDir, itemFile.getName());
//writing into destination file.
item.write(destFile);
insertData(fileName, reqIp);
getResponse().setEntity(302: file received successfully,
MediaType.TEXT_PLAIN);
}
} catch (Exception ex) {
System.out.println(Oops...EXCEPTION !!!);
}
}
}
}
Regards ...
--
View this message in context:
http://n2.nabble.com/Upload-to-Directory-tp2438898p2604760.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1595300
RE: Restlet 1.2 M2 released [throw previous email away]
Hi Paul, I agree with your comment, the knowledge of Restlet specific extensions shouldn't be required by the clients. Actually, the TunnelService already allows you to specify the full media type name or character set or language. Therefore, /myPath?media=text/xml will work. In the annotation case, the usage of extensions is purely internal to Restlet and doesn't have to be exposed or known by clients. This is even orthogonal to the TunnelService feature. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com _ De : Paul Austin [mailto:mail-li...@revolsys.com] Envoyé : mardi 7 avril 2009 20:25 À : discuss@restlet.tigris.org Objet : Re: Restlet 1.2 M2 released [throw previous email away] Jerome, I would be happy if users can choose to either use the extensions or the mime-type where the extension is currently used. Consider a web service which is designed to be used either from a web browser when the media= parameter is used or from a Java client where the accept header can be set. In the documentation for this web service it would be useful to be able to list only the mime types. Rather than saying, if you use the media parameter use the keyword xhtml or if you use the accept header use application/xhtml+xml. Another thing to consider is if you describe your service using WADL you would be using the mime types so the client using the media= parameter would need to know the mapping to/from mime type to media type. i.e. you need a public extensions registry. Just some thoughts, Paul -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1594388
Re: Grizzly Https Server
am actually lookin for a grizzly https server.. Hi Sheshakiran, Are you looking for using Grizzly or Restlet with the Grizzly connector? In Restlet, SSL support has been harmonised using an SslContextFactory for all the connectors. It supports client-certificate authentication (provided your configure it with the trust store you require.) If it's for Grizzly only, I'd suggest posting to the Grizzly list. Coincidentally, I've just made a few suggestions for improvement in Grizzly, but these don't affect Restlet and its use of Grizzly. (Note that the default should work at least, that is, specifying the keystore/truststore using the usual javax.net.ssl.* system properties, in Grizzly and Restlet.) Best wishes, Bruno. srsk wrote: Hi, I am Sheshakiran, developer from one of the service based industry. I have a requirement to develop one Grizzly Asynhcronous Https Server, which would do Basic Authentication and HTTPCertificate validation. I found Http implementation of grizzly server, but i am not able to get sufficient information on Grizzly Https implementation. Any kind of help would be really appreciable. Https should accept inputs like 1) Username and Password and 2) Certificate details like i) Keystore ii) Trusted certificate iii) passwords for keystore and certificate iv) private key alias and private key password ... thanks .. Sheshakiran -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1578563 -- View this message in context: http://n2.nabble.com/Grizzly-Https-Server-tp2599248p2604563.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1594713
Re: CSS and HTTPS problem ...
Many thanks Rob, i'll consider that .. will give it a try and feedback whenever possible You'd have to change the CSS to also reference the images, etc. over https. The warning you describe will be triggered whenever you have an HTML page, delivered over https, that calls images, CSS, or javascript from another source, delivered over http. This isn't a Restlet thing ... it applies to any SSL Web server. However, one neat Restlet thing that does help, is the Redirector feature. This is a bit advanced, but you can use the Redirector on your local web service to proxy these requests to the other server; this can be used to avoid such warnings and single-source issues, at the expense of some overhead in your web service and a responsibility to manage the security appropriately. - Rob -- View this message in context: http://n2.nabble.com/CSS-and-HTTPS-problem-...-tp2544622p2604784.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1595403
RE: Restlet 1.2 M2 released [throw previous email away]
Tal, The MetadataService isn't restricted at all to mapping filename extensions. As I pointed out previously, it is already used by the TunnelService to customize client preferences, which has nothing to do with files. From where do you get this impression? Maybe we could clarify some documentation? Regarding the @Get(jpg | jpeg | jpe): first it should allowed, maybe generating a log/warning about the redundancy. Then proper examples and documentation will help clarifying this edge case. I really don't see any design issue here. Quite on the opposite, I even see advantages of using a single consistent registry. Probably we should give this more time to mature, and wait for further feed-back. As always, if proven wrong, I'm always happy to change my mind. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com _ De : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : mardi 7 avril 2009 20:35 À : discuss@restlet.tigris.org Objet : Re: Restlet 1.2 M2 released [throw previous email away] I like the idea of having a default Extension for each MediaType, which means that they are all mappable. I understand the multiple uses of the word Extension, but my problem is the multiple uses of Extension itself in Restlet. :) The MetadataService really is used for mapping filename extensions, not only for parsing MediaTypes. I just feel uncomfortable about this mix of uses. Specifically, consider that the filename extensions use requires that have a many-to-one mapping of MediaTypes. For an example of how this can confuse users, a user might think that they need to do this in order to fully support all requests for JPEG format: @Get(jpg | jpeg | jpe) Those three extensions are indeed registered right now in MetadataService. However, they all point to MediaType.IMAGE_JPEG, and this is superfluous. So, somewhere in the documentation it must be emphasized to the user that we are not referring to filename extensions here, but rather the MIME types, and that only one Extension would be enough. I feel that this kind of awkward explanation can be easily avoided with a one-to-one mapping of shortcuts, and a separate registry to handle filename extension one-to-many mapping. Separate uses, separate mechanisms. -Tal Jerome Louvel wrote: Tal, It's really a matter of terminology, so it's hard to rationalize the choice. I know that extension is often synonymous of file extension but it doesn't have to. If you look at WordNet definition of the extension word, you should feel more comfortable about using it as an equivalent to shortcut: http://wordnetweb.princeton.edu/perl/webwn?s=extension The advantage of this terminology is that it maps directly to the file extension concept which is widely known, but is more generic: you need to update your mental mapping for this word, not always easy ;). We already use it in the TunnelService to customize the Accept header value via the URIs or in the Reference class to manipulate them (see getExtensions() method). I realize that there is some documentation and clarification work to be done, but I don't think it is misleading as a term. Regarding the application/www-form-urlencoded media type, the solution is simply to add a common extension mapping for it. This is now available in SVN trunk as the form extension. If it wasn't available by default, you could just specify it yourself at application start: getMetadataService().addExtension(form, MediaType.APPLICATION_WWW_FORM); One way to guarantee that each metadata has a matching extension would be to add an extension property to the Metadata class. We could then update the MetadataService to simplify the mapping: getMetadataService().addExtension(MediaType.APPLICATION_WWW_FORM); In some way, the metadata service would become a registry of all available metadata. We could add a MetadataService#registry property of type Metadata, resulting in this code: getMetadataService().getRegistry().add(MediaType.APPLICATION_WWW_FORM); Regarding the failure, I believe I did mention that the goal is to have full parsing/validation of the annotation value string with proper warning message. So your concern will definitely be addressed! Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com _ De : Tal Liron [mailto:tal.li...@threecrickets.com] Envoyé : mardi 7 avril 2009 19:51 À : discuss@restlet.tigris.org Objet : Re: Restlet 1.2 M2 released [throw previous email away] Thanks for joining the discussion, Jerome, we were getting a bit ridiculous in trying to second guess your intentions. :) It makes sense to me to use simple strings for referring to media types, and your examples are
Re: Comments on First Resource article (Restlet 1.2m2)
Hi Tim,
many thanks, it helps reducing the number of lines of code.
Best regards,
Thierry Boileau
Great. One more thing -- the code in ItemResource should also use the
return value of putIfAbsent to decide whether the item was created or
updated:
@Put
public void storeItem(Representation entity) throws IOException {
// The PUT request updates or creates the resource.
if (item == null) {
item = new Item(itemName);
}
// Update the description.
Form form = new Form(entity);
item.setDescription(form.getFirstValue(description));
// Update the item in the list.
if (getItems().putIfAbsent(item.getName(), item) == null) {
setStatus(Status.SUCCESS_CREATED);
} else {
setStatus(Status.SUCCESS_OK);
}
}
On Tue, Apr 7, 2009 at 3:45 AM, Thierry Boileau
thierry.boil...@noelios.com mailto:thierry.boil...@noelios.com wrote:
Hi Tim,
thanks a lot for your useful comments!
Ive updated the sample code.
The call to putIfAbsent needs to be prefixed with getItems().
Actually, I created a putIfAbsent method on the BaseResource class
because I was not aware you meant to use a ConcurrentMap.
best regards,
Thierry Boileau
Great, thanks! Just a few more tweaks:
The type of the items field in FirstResourceApplication and the
return
type of getItems() in FirstResourceApplication and BaseResource
should
be ConcurrentMap, in order to have access to the putIfAbsent method.
There's no need to repeat the construction of ConcurrentHashMap
in the
two constructor bodies -- it only raises the question of why it was
written that way. Better to initialize at the declaration point and
keep the constructors simple:
ItemsResource could be simplified by removing the CollectionItem
items field and the doInit method and simply using
getItem().values()
in the for loop in the @Get method. You already have a more
substantive example of using doInit in ItemResource.
private final ConcurrentMapString, Item items
= new ConcurrentHashMapString, Item();
public FirstResourceApplication(Context context) {
super(context); }
public FirstResourceApplication() {}
The sentence immediately preceding the FirstResourceApplication
code,
That's why you will notice that the map of items is made final
and is
an instance of the ConcurrentHashMap class. should probably be
something like That's why you will notice that the map of items
is a
final reference to a ConcurrentMap, rather than a plain Map. The
concrete type, ConcurrentHashMap, is not the point -- it could
be any
implementation of ConcurrentMap, e.g., something produced by Google
Collections' MapMaker.
The call to putIfAbsent needs to be prefixed with getItems().
--tim
On Mon, Apr 6, 2009 at 5:09 AM, Thierry Boileau
thierry.boil...@noelios.com
mailto:thierry.boil...@noelios.com
mailto:thierry.boil...@noelios.com
mailto:thierry.boil...@noelios.com wrote:
Hi Tim,
thanks a lot for your comments! The sample code has been
updated.
best regards,
Thierry Boileau
The introduction has ...which means that you don't need
to take
care
of thread-safe concerns. which should be thread-safety
concerns.
This might still be a little strong, as you still have to
worry
about
thread-safety in all the objects that your Resources refer to
that are
shared between threads. You could say that you don't need to
make your
resource subclasses thread-safe, but that sounds
anticlimactic.
That's why you will notice that the map of items is made
immutable
and is an instance of the ConcurrentHashMap class. You mean
final,
not immutable. In actual practice, you'd really want to
make the
items field a ConcurrentMap rather than just Map, because
the @Post
and @Put methods defined below would then be able to use
putIfAbsent
to avoid races. I know you want to keep the example
simple, but I'd
hate for readers to draw the conclusion that they don't
have to
worry
about races:
// Register the new item if one is not already registered.
if (!getItems().containsKey(itemName)
getItems().putIfAbsent(itemName, new
Item(itemName,
itemDescription)) == null) {
// Set the response's status and entity
setStatus(Status.SUCCESS_CREATED);
Representation
RE: Restlet 1.2 M2 released [throw previous email away]
Dave,
The interest in extensions is that they provide compact shortcuts for media
types/languages/encodings/character sets. It is easy to remember json,
harder to remember about application/json, and I'm not talking about the
media type for Web forms.
So, it's really about usability and clarity of the resulting source code. My
view is that annotations shouldn't become too prominent when used, they
should be kept a simple as possible, like the standard @Override,
@Deprecated or @SuppressWarnings annotations.
I prefer coding in Java instead of a pseudo-annotation language. It's also a
matter of taste and obviously those preferring extensive use of annotations
will be happy with JAX-RS (that we also support as a Restlet extension).
Regarding the annotation value syntax, it isn't fixed yet and I'm looking
for feed-back. We should progressively implement it to make sure it
corresponds to real use cases. At least we have a target design that we can
refer to.
How would your annotations look if we were using string arrays or several
annotations? How would you express common cases like POST accepting either
entity with either XML or JSON as media type and in either English or French
as language, and returning XML or JSON depending on the input media type?
Regarding the comparison to JAX-RS, I agree that it will be inevitable.
Let's look at it right now :)
With JAX-RS API:
@GET
@Produces(application/x-www-form-urlencoded)
public String toString() {
return ...;
}
With Restlet API:
-
@Get(form)
public String toString() {
return ...;
}
With JAX-RS API:
@PUT
@Consumes({application/json, application/xml,
application/x-www-form-urlencoded})
@Produces({text/plain})
public String store(String value)
{
...
}
With Restlet API:
-
@Put(txt:json|xml|form)
public String store(String value)
{
...
}
Note that there are other very significant differences between both APIs,
like for dealing with routing (URI/path mapping to resources). I just
covered the variant description aspect.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : David Fogel [mailto:carrotsa...@gmail.com]
Envoyé : mardi 7 avril 2009 20:42
À : discuss@restlet.tigris.org
Objet : Re: Restlet 1.2 M2 released [throw previous email away]
Hi Jerome-
I don't know, this whole extension thing sounds strange to me. Why replace
a well-defined, standardized namespace for media-types (e.g.
text/html etc) with a new, ad-hoc, non-standard namespace like this
extension stuff?
I don't think that the goal of compactness is a good justification for
this!
I think I understand that you want to support other variant metadata like
language and character-set, but those, too, have standardized namespaces!
I think it's important to be _very_ cautious about introducing new text
string grammars- most of the time it would be better to use java language
syntax instead. The challenge here is that you're trying to squeeze a lot
of structured metadata into an annotation value. That certainly narrows the
options available. But maybe you could use a more straightforward array of
Strings? or have multiple annotations?
Or perhaps it would be better to require the user to define more than one
method to split apart the variant options, even if those methods call the
same implementation?
I'm just not feeling confident that this solution is going to feel elegant
when it's done. And it might be a good idea to keep in mind that whatever
you end up with here will likely get frequently compared to JAX-RS. And
jax-rs's story here, although perhaps less flexible, may end up seeming
simpler.
-Dave Fogel
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15815
89
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334
RE: ServerResource is currently incompatible with OSGi
Hi all,
Beautiful! This new solution is available in SVN trunk.
Thanks Dave for the report and Tim for the clever fix!
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org/
http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
http://www.noelios.com
_
De : tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de Tim
Peierls
Envoyé : mercredi 8 avril 2009 00:23
À : discuss@restlet.tigris.org
Objet : Re: ServerResource is currently incompatible with OSGi
Why involve Context at all? The AnnotationInfo associated with a Class?
extends UniformResource does not depend on Context. You could just add a
method to AnnotationUtils:
public static AnnotationInfo getAnnotationDescriptor(Class? extends
UniformResource resourceClass) {
AnnotationInfo result = cache.get(resourceClass);
if (result == null) {
result = computeAnnotationDescriptor(resourceClass); // use code from
existing getAnnotationDescriptors for this
AnnotationInfo prev = cache.putIfAbsent(resourceClass, result);
if (prev != null) result = prev;
}
return result;
}
private static final ConcurrentMapClass? extends Resource,
AnnotationInfo cache =
new ConcurrentHashMapClass? extends Resource, AnnotationInfo();
Then you don't need getAnnotationDescriptors. You probably want a way to
clear cache entries if a class is reloaded, say.
You could get more fancy, with Futures and such, but I think that would be
wasted effort.
--tim
On Tue, Apr 7, 2009 at 1:20 PM, Tal Liron tal.li...@threecrickets.com
wrote:
Ah, I can see your point now.
I would recommend, then, that a Context would have two separate
ConcurrentHashMaps, something like this:
1. Context.getConfiguration() -- this would be for the user
2. Context.getImplementationCache() -- this would be for things like
AnnotationUtils, and the user should not normally look at this, except
perhaps for debugging
-Tal
David Fogel wrote:
Hi Tal-
I think what you suggested about appending a classloader id (perhaps
System.identityHashCode(cl) ?) would work.
Regarding the Restlet Context and this cache being cruft: You say
the Context is a reasonable place for information that applies to the
Application, but this doesn't have annotation cache doesn't have
anything to do with my Application, it's related to a hidden
_implementation_ detail. As an end-user, we're not meant to be using
this annotion info cache directly. Yet the Context, as a very
prominent and unavoidable part of the Restlet public API is meant to
be used and understood. That's why I think it isn't a good place to
stash implementation-related data like this annotation stuff.
-Dave
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1572
499 dsMessageId=1572499
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596661
RE: Multipart parsing
Hi Fabio, We have some parsing login here: org.restlet.engine.http.HttpClientCall#parseContentDisposition(String):Strin g It extracts the file name field only. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Fabio Mancinelli [mailto:fabio.mancine...@gmail.com] Envoyé : lundi 6 avril 2009 18:50 À : discuss@restlet.tigris.org Objet : Multipart parsing Dear all, I am using JAX-RS for handing a Multipart form for file upload. I have a method: @POST @Consumes(MediaType.MULTIPART_FORM_DATA) public Attachment addAttachment(Multipart multipart) ... Now the problem is that multipart contains information to be parsed in order to be extracted (I am talking about form fields) Something like: Content-Disposition : form-data; name=field1 Content-Disposition : form-data; name=field2 Content-Disposition : form-data; name=file; filename=someuploadedcontent.png Is there already, in Restlet, a convenient way for parsing this kind of thing or should I write some pattern matching magic? Cheers, Fabio -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15630 72 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596724
RE: Spring + Restlet 1.2-SNAPSHOT, NullPointerException
Hi Kevin and Eric, I've added a check in Finder to make it work even if targetClass is null. This is a temporary workaround that will need to be improved in order to make SpringFinder support the new resource API. BTW, this support will be cleaner that with the Resource class because ServerResource has only one default constructor. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com _ De : Kevin Conaway [mailto:kevin.cona...@gmail.com] Envoyé : mercredi 8 avril 2009 14:20 À : discuss@restlet.tigris.org Objet : Re: Spring + Restlet 1.2-SNAPSHOT, NullPointerException Hi Jerome, There is a bug specifically with the SpringFinder class.� The parent Finder was refactored such that it now checks to see that the targetClass property is an instance of Handler.� Previous versions of the class did not depend on targetClass to be non-null. Since the SpringFinder only deals with the createResource() method, the targetClass property is always null. Eric, as a temporary workaround, you can create your own SpringFinder class that overrides getTargetClass() to always return Resource.class.� Or you can set the targetClass property on all your SpringFinder instances. Kevin On Tue, Apr 7, 2009 at 1:35 PM, Jerome Louvel jerome.lou...@noelios.com wrote: Hi Eric, � Here is a sample configuration attached. You can check the source code here: http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet.test/src/org/restlet/test/ext/spring/ � Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder�~ http://www.noelios.com/ http://www.noelios.com � _ De�: Eric Hough [mailto:k2e...@gmail.com] Envoy��: vendredi 3 avril 2009 21:32 ��: discuss@restlet.tigris.org Objet�: Spring + Restlet 1.2-SNAPSHOT, NullPointerException I've been having trouble getting Spring to play nice with Restlet (I'm experienced with Spring, a newbie with Restlet, so please bear with me!). Using Spring 2.5.6 and Restlet 1.2-SNAPSHOT. I want to define a resource called uniq and map /uniq to my UniqResource bean (extends Resource). Simple, yeah? When I browse to http://localhost:8182/uniq, I get the following stack trace: Apr 3, 2009 10:54:19 AM org.restlet.engine.StatusFilter getStatus SEVERE: Unhandled exception or error intercepted java.lang.NullPointerException at java.lang.Class.isAssignableFrom(Native Method) at org.restlet.resource.Finder.handle(Finder.java:391) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:520) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:520) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Router.handle(Router.java:520) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.engine.StatusFilter.doHandle(StatusFilter.java:153) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.routing.Filter.doHandle(Filter.java:156) at org.restlet.routing.Filter.handle(Filter.java:201) at org.restlet.engine.ChainHelper.handle(ChainHelper.java:126) at org.restlet.Component.handle(Component.java:724) at org.restlet.Server.handle(Server.java:355) at org.restlet.engine.ServerHelper.handle(ServerHelper.java:71) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:149) at org.restlet.engine.http.StreamServerHelper$ConnectionHandler.run(StreamServerHelper.java:89) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Apr 3, 2009 10:54:19 AM org.restlet.engine.LogFilter afterHandle INFO: 2009-04-03 10:54:19 127.0.0.1 - - 8182 GET /uniq - 500 365 - 39 http://localhost:8182 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.10 (intrepid) Firefox/3.0.8 - Here's my applicationContext.xml: ?xml version=1.0 encoding=UTF-8? beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd; bean id=springComponent class=org.restlet.ext.spring.SpringComponent init-method=start destroy-method=stop property name=server bean
RE: How to Fetch Request XML in Java Restlet
Hi Rick, You should look at the example code provided in Restlet distribution, for example this package is interesting: http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet.ex ample/src/org/restlet/example/book/restlet/ch8/ Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Rick [mailto:freephon...@yahoo.com] Envoyé : mercredi 8 avril 2009 01:50 À : discuss@restlet.tigris.org Objet : How to Fetch Request XML in Java Restlet Hi, I'm trying to use java restlet. I'll be getting the input in the XML format I need to store the data in database return back the response back in XML format. Does any one have sample code which accepts input in XML then stores in DB returns response in XML? How to fetch the request in XML format in Java restlet? I'll really appreciate if some one can elaborate in detail!! Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15861 79 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596906
Re: [1.1.3] Tomcat + RestletFrameworkServlet mapping SpringBeanRouter to /
Jerome,
The one problem in the case I described is that it is not possible to use
as the resource path in this case as you cannot specify an empty bean alias
in the spring mapping file.
One approach around this would be to have a
SpringBeanRouter.setDefaultAttachment(String beanName) method which would
allow me to set the default restlet. Could you also have a
setAttachment(String path, String beanName) method and
setAttachments(ListString beanNames)
bean
id=router
class=...SpringBeanRouter
p:defaultAttachment=myRootResource
/
BTW setXXX methods are easier to work with in Spring than using methods such
as attach.
Paul
On Wed, Apr 8, 2009 at 4:12 AM, Jerome Louvel jerome.lou...@noelios.comwrote:
Paul,
The problem is that the URI without the trailing slash isn't equivalent to
the one with it. It's true that in many cases, people assume it is
equivalent but it doesn't have to.
Also, relative URIs can be expressed in the same way if the ends with a
slash or not, leading to further routing issues. The only way we found to
clean that is to force the client to redirect itself to the URI with a
slash. However, it isn't something we should do automatically.
BTW, there is a related RFE:
Improve matching of directory URIs
http://restlet.tigris.org/issues/show_bug.cgi?id=532
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
--
*De :* Paul Austin [mailto:mail-li...@revolsys.com]
*Envoyé :* mardi 7 avril 2009 21:58
*À :* discuss@restlet.tigris.org
*Objet :* Re: [1.1.3] Tomcat + RestletFrameworkServlet mapping
SpringBeanRouter to /
Here is a class which fixes the issue. Probably a better solution would be
to change the Route class so that if the remainingPart is it sets it to
/ before doing the regex matching. On a related note is it possible to
force exact matching so that say /apps would be mapped but not /apps/xyz?
public class RootSpringBeanRouter extends SpringBeanRouter {
@Override
public void handle(Request request, Response response) {
Reference resourceRef = request.getResourceRef();
if (resourceRef.getRemainingPart().equals()) {
resourceRef.addSegment();
}
super.handle(request, response);
}
}
On Tue, Apr 7, 2009 at 12:27 PM, Paul Austin mail-li...@revolsys.comwrote:
In my project I am deploying an application as a war file. The root of the
web application /* is mapped to the RestletFrameworkServlet so that all
handling is performed by Restlet.
servlet
servlet-namebpf/servlet-name
servlet-classcom.noelios.restlet.ext.spring.RestletFrameworkServlet/servlet-class
/servlet
servlet-mapping
servlet-namebpf/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
The root restlet is a SpringBeanRouter and I have a mapping for / to a
resource as shown below.
bean id=root class=org.restlet.ext.spring.SpringBeanRouter /
bean
name=/
id=rootResource
scope=prototype
class=myResourceClass
/
The war is deployed to /ws on my server.
If I access /ws I get an Restlet status page error saying The server has
not found anything matching the request URI but if I use /ws/ it works
correctly.
I tried mapping to to see if that would work and it gives the same
behaviour.
Is it possible to modify the router so that the root resource does not
need the trailing slash?
Cheers,
Paul
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1597319
restlet with jdbc
Hey, I want to create a database resource with jdbc connection. I have read a lot of documentation this week but I don't know how i can integrate jdbc in a restlet resource! I want a user to login with a username and password (saved in the database) for the beginning and then do some user related stuff! Can someone help me please! Thx -- View this message in context: http://n2.nabble.com/restlet-with-jdbc-tp2605333p2605333.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596641
RE: [NEWBIE] RESTlet with JDBC tutorial
I am solving with the same problem! I want to create a database resource with jdbc connection. I have read a lot of documentation this week but I don't know how i can integrate jdbc in this samples! I want a user to login with a username and password (saved in the database) for the beginning and then do some user related stuff! Can someone help me please! Thx Hi there, Just look at the example provided with Restlet (org.restlet.example packages). You will see how persistence of resource's state is done. It should then be straightforward to adapt that to JDBC/Hibernae/JPA or similar technologies. Nothing really Restlet specific here. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : webp...@tigris.org [mailto:webp...@tigris.org] Envoyé : mercredi 1 avril 2009 18:47 À : discuss@restlet.tigris.org Objet : [NEWBIE] RESTlet with JDBC tutorial Do anybody know where can I find tutorials to understand how to implement simple resources with persistence through JDBC (ex: MySQL, ...) ? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15088 25 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1532664 -- View this message in context: http://n2.nabble.com/-NEWBIE--RESTlet-with-JDBC-tutorial-tp2570201p2605328.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596609
Re: Annotations and Restlet's future
I can see that Jérôme has already answered a great deal of my questions in this thread :) http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334 Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596551
Re: Resource factories
On Tue, Apr 7, 2009 at 10:28 AM, Kyrre Kristiansen
kyrre_kristian...@yahoo.co.uk wrote:
This resulted in using Generics on my resources, where I created a class,
ListResourceT extends Referrable (where Referrable is an interface, with
one method, getId() ). ... a concrete class that relies solely on one
object, the config, and that works with any resource that represents a
Referrable subtype and is a top-level list resource.
This, however, is where my trouble starts. Because at run-time, the system
cannot differentiate between a ListResourceFoo.class and a
ListResourceBar.class due to type erasure. At the moment I have to
subclass ListResource for each type I am using it for, but hopefully making
a parametrized Finder class that can then be attached to a Router, will
solve my troubles. Has anyone tried this?
You can get this for free with the Guice-Restlet integration work described
here:
http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html
You'd write something like this in your Restlet wiring code:
router.attach(/foo/{id}, finderFor(new
TypeLiteralListResourceFoo(){})); // curly braces required!
router.attach(/bar/{id}, finderFor(new
TypeLiteralListResourceBar(){}));
router.attach(/baz/{id}, finderFor(new
TypeLiteralListResourceBaz(){}));
where finderFor would be defined like this:
private T Finder finderFor(TypeLiteralT typeLiteral) {
return finderFactory.finderFor(Key.get(typeLiteral));
}
Then in your binding code, you'd create a binding for each ListResourceX
that you wanted to support. You'd even be able to provide custom
implementations for certain types. For example, if you needed a special
subclass of ListResourceBaz to handle /baz/{id} -- while Foo and Bar just
needed the standard ListResource -- you could bind it differently in your
binding code, and the router.attach(/baz/{id}, ...) line would remain the
same.
Of course, this approach assumes Guice, which might not be an option for
you. But the same technique could eventually be supported directly by
Restlet.
--tim
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596473
Annotations and Restlet's future
Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596005
Re: Restlet and maven
Hi ! Thanks all for your answers. I was not really worried about building the project with ant or maven. I use maven to build most of my projects and I want to test them with last updates. As maven.restlet.org is not being updated everyday ;). Cheers, Rémi On Tue, Apr 7, 2009 at 17:02, Davide Angelocola davide.angeloc...@gmail.com wrote: Hi Rémi, assuming you've installed maven in the PATH you must run the following command in trunk/modules: mvn install using netbeans is even easier, just install the maven plugin and open the modules project. Then build the project. Best Regards, Davide Angelocola 2009/4/7 Rémi Dewitte r...@gide.net Hello, I know there is some ongoing work about maven and restlet. If I checkout the trunk and build it, how do I install the new artifacts into my local m2 repository ? Thanks, Rémi -- -- Davide Angelocola -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1595694
Re: [1.1.3] Tomcat + RestletFrameworkServlet mapping SpringBeanRouter to /
Jerome,
Here is an implementation which extends SpringBeanRouter, it could easily be
integrated into the super class.
import java.util.Map;
import java.util.Map.Entry;
import org.restlet.Finder;
import org.restlet.ext.spring.SpringBeanRouter;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
public class SpringRouter extends SpringBeanRouter implements
BeanFactoryAware {
private BeanFactory beanFactory;
public void setAttachment(String uriPattern, String beanName) {
Finder finder = createFinder(beanFactory, beanName);
attach(uriPattern, finder);
}
public void setAttachments(MapString, String attachments) {
for (EntryString, String attachment : attachments.entrySet()) {
String uriPattern = attachment.getKey();
String beanName = attachment.getValue();
setAttachment(uriPattern, beanName);
}
}
public void setBeanFactory(BeanFactory beanFactory) throws BeansException
{
this.beanFactory = beanFactory;
}
public void setDefaultAttachment(String beanName) {
String uriPattern = ;
setAttachment(uriPattern, beanName);
}
}
Paul
On Wed, Apr 8, 2009 at 4:12 AM, Jerome Louvel jerome.lou...@noelios.comwrote:
Paul,
The problem is that the URI without the trailing slash isn't equivalent to
the one with it. It's true that in many cases, people assume it is
equivalent but it doesn't have to.
Also, relative URIs can be expressed in the same way if the ends with a
slash or not, leading to further routing issues. The only way we found to
clean that is to force the client to redirect itself to the URI with a
slash. However, it isn't something we should do automatically.
BTW, there is a related RFE:
Improve matching of directory URIs
http://restlet.tigris.org/issues/show_bug.cgi?id=532
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
--
*De :* Paul Austin [mailto:mail-li...@revolsys.com]
*Envoyé :* mardi 7 avril 2009 21:58
*À :* discuss@restlet.tigris.org
*Objet :* Re: [1.1.3] Tomcat + RestletFrameworkServlet mapping
SpringBeanRouter to /
Here is a class which fixes the issue. Probably a better solution would be
to change the Route class so that if the remainingPart is it sets it to
/ before doing the regex matching. On a related note is it possible to
force exact matching so that say /apps would be mapped but not /apps/xyz?
public class RootSpringBeanRouter extends SpringBeanRouter {
@Override
public void handle(Request request, Response response) {
Reference resourceRef = request.getResourceRef();
if (resourceRef.getRemainingPart().equals()) {
resourceRef.addSegment();
}
super.handle(request, response);
}
}
On Tue, Apr 7, 2009 at 12:27 PM, Paul Austin mail-li...@revolsys.comwrote:
In my project I am deploying an application as a war file. The root of the
web application /* is mapped to the RestletFrameworkServlet so that all
handling is performed by Restlet.
servlet
servlet-namebpf/servlet-name
servlet-classcom.noelios.restlet.ext.spring.RestletFrameworkServlet/servlet-class
/servlet
servlet-mapping
servlet-namebpf/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
The root restlet is a SpringBeanRouter and I have a mapping for / to a
resource as shown below.
bean id=root class=org.restlet.ext.spring.SpringBeanRouter /
bean
name=/
id=rootResource
scope=prototype
class=myResourceClass
/
The war is deployed to /ws on my server.
If I access /ws I get an Restlet status page error saying The server has
not found anything matching the request URI but if I use /ws/ it works
correctly.
I tried mapping to to see if that would work and it gives the same
behaviour.
Is it possible to modify the router so that the root resource does not
need the trailing slash?
Cheers,
Paul
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1597991
Re: DirectoryResource throws/logs useless exceptions for CLAP protocol
This is something that concerns me, too, as I'd much rather have my applications purely in the Restlet API without reverting specifically to the connector. I've been using Directory, too, in production and without any issue except my uneasiness about performance. I have not dared use it (yet) in performance-intensive situation. I'm wondering if it's worth, in addition to Restlet's Directory, to support a simple connector-agnostic wrapper that would use the underlying DefaultServlet or whatever. The Grizzly and Jetty projects already are doing superb work on optimization of serving static files, and we might as well wrap it! I see it as a lowest-common-denominator kind of API, which just sets up a filesystem-to-HTTP server and offers minimal fiddling. Of course, I'm not expecting such a wrapper to return nice Restlet representations which we can Filter. It would be a "black box" as far as the Restlet API is concerned. Still, I think this would be very useful. Many users (myself included) turn to Restlet in order to create performative applications. Serving static files should be part and parcel of this. -Tal Jerome Louvel wrote: Dave, Thanks for looking at the details on Directory implementation. This are certainly opportunities to refactor and optimize this class. As you found out, it is handling pretty complex stuff. We would welcome some contributions in this area. We have also received a report regarding performance issue of Directory used with the WAR client that we need to inspect. This might be due to the same reason: "Improve performance of WAR client" http://restlet.tigris.org/issues/show_bug.cgi?id=736 Regarding the production ready status, we have been using this class on all our Web sites with no trouble so far. Would you mind creating a bug report for what you found? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder~ http://www.noelios.com De: Rob Heittman [mailto:rob.heitt...@solertium.com] Envoy: mardi 7 avril 2009 14:26 : discuss@restlet.tigris.org Objet: Re: DirectoryResource throws/logs useless exceptions for CLAP protocol I also wish it were a bit faster. We do serve several hundred thousand impressions out of Directory every month, but we serve several million using thinner Resources not wrapped in Directory -- not sure what would happen if we wrapped those in Directory. On Tue, Apr 7, 2009 at 1:58 AM, David Fogel carrotsa...@gmail.com wrote: The Directory class is the only built-in way for plain, non-servlet, Restlet apps to serve static content. Should we consider it "production"-ready w.r.t. performance under load? Another way of asking this: is the Directory class a reasonable substitute for, e.g. Jetty's DefaultServlet?
Re: Restlet 1.2 M2 released [throw previous email away]
Then
perhaps TunnelService shouldn't be using extension names, either. ;)
Sure,
let's get more feedback. I just want to point out that this is a matter
of taste and clarity rather than any technical issue. As for my taste,
tou haven't managed to change it, yet.
I
think things are very clear to you because you've been swimming in
Restlet for years, but for new users, who will try to wrap their mind
around how to write a Resource and even what exactly a Resource is,
will be confused by the introduction of what appear to be
filename extensions. The reason is that actual, real filename
extensions are always part of the mix, whether as files existing on the
filesystem or in the resource's URI. (Even worse, Restlet uses the word
"extension" to refer to its plugin system -- there's one more layer of
potential confusion here.)
The
more I think about it, the more I think that shortcuts should be
optional, and that the full, complete MIME type should be used, especially
in the tutorials. Clarity should come above everything. If the
technical issue is that the "/" character is used by the grammar, then
perhaps we need a better grammar that treats "/" as part of the lexical
item.
This
is an important issue. I really hope other Restlet users will chime in
to express their opinion on this matter. Like Jerome, I'm very willing
to be convinced that my position creates more problems than it solves!
-Tal
Jerome Louvel wrote:
Tal,
The MetadataService isn't restricted at all to
mapping filename extensions. As I pointed out previously, it is already
used by the TunnelService to customize client preferences, which has
nothing to do with files. From where do you get this impression? Maybe
we could clarify some documentation?
Regarding the @Get("jpg | jpeg | jpe"): first it
should allowed, maybe generating a log/warning about the redundancy.
Then proper examples and documentation will help clarifying this edge
case. I really don't see any design issue here. Quite on the opposite,
I even see advantages of using a single consistent registry.
Probably we should give this more time to
mature, and wait for further feed-back. As always, if proven wrong, I'm
always happy to change my mind.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder~ http://www.noelios.com
De: Tal Liron
[mailto:tal.li...@threecrickets.com]
Envoy: mardi 7 avril 2009 20:35
: discuss@restlet.tigris.org
Objet: Re: Restlet 1.2 M2 released [throw previous email away]
I like the idea of having a default Extension
for each MediaType, which means that they are all mappable.
I understand the multiple uses of the word Extension, but my problem is
the multiple uses of Extension itself in Restlet. :) The
MetadataService really is used for mapping filename extensions, not
only for parsing MediaTypes. I just feel uncomfortable about this mix
of uses. Specifically, consider that the filename extensions use
requires that have a many-to-one mapping of MediaTypes. For an example
of how this can confuse users, a user might think that they need to do
this in order to "fully" support all requests for JPEG format:
@Get("jpg | jpeg | jpe")
Those three extensions are indeed registered right now in
MetadataService. However, they all point to MediaType.IMAGE_JPEG, and
this is superfluous. So, somewhere in the documentation it must be
emphasized to the user that we are not referring to filename extensions
here, but rather the MIME types, and that only one Extension would be
enough. I feel that this kind of awkward explanation can be easily
avoided with a one-to-one mapping of shortcuts, and a separate registry
to handle filename extension one-to-many mapping. Separate uses,
separate mechanisms.
-Tal
Jerome Louvel wrote:
Tal,
It's really a matter of terminology, so it's
hard to rationalize the choice. I know that "extension" is often
synonymous of "file extension" but it doesn't have to. If you look at
WordNet definition of the "extension" word, you should feel more
comfortable about using it as an equivalent to "shortcut":
http://wordnetweb.princeton.edu/perl/webwn?s=extension
The advantage of this terminology is that it
maps directly to the "file extension" concept which is widely known,
but is more generic: you need to update your mental mapping for this
word, not always easy ;). We already use it in the TunnelService to
customize the "Accept" header value via the URIs or in the Reference
class to manipulate them (see getExtensions() method). I realize that
there is some documentation and clarification work to be done, but I
don't think it is misleading as a term.
Regarding the "application/www-form-urlencoded"
media type, the solution is simply to add a common extension mapping
for it. This is now available in SVN trunk as the "form" extension. If
Re: ServerResource is currently incompatible with OSGi
Hmm.
I disagree that this has nothing to do with the Application.
For example, if an Application is unloaded, this cached information
will remain in the static field. In fact, there is no mechanism in
place right now clean this cache, and in dynamic environments (possibly
OSGi) it may accumulate "cruft." Not a huge problem, but this is the
stuff memory leaks are made of...
Here's
a thought: can we use a synchronized WeakHashMap here? That way, the
AnnotationInfo would be discarded when the class is unloaded.
-Tal
Jerome Louvel wrote:
Hi all,
Beautiful! This new solution is available in SVN
trunk.
Thanks Dave for
the report and Tim for the clever fix!
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder~ http://www.noelios.com
De:
tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de
Tim Peierls
Envoy: mercredi 8 avril 2009 00:23
: discuss@restlet.tigris.org
Objet: Re: ServerResource is currently incompatible with OSGi
Why involve Context at all? The AnnotationInfo associated with a
Class? extends UniformResource does not depend on Context. You
could just add a method to AnnotationUtils:
public static AnnotationInfo getAnnotationDescriptor(Class?
extends UniformResource resourceClass) {
AnnotationInfo result = cache.get(resourceClass);
if (result == null) {
result = computeAnnotationDescriptor(resourceClass); // use code
from existing getAnnotationDescriptors for this
AnnotationInfo prev = cache.putIfAbsent(resourceClass, result);
if (prev != null) result = prev;
}
return result;
}
private static final ConcurrentMapClass? extends
Resource, AnnotationInfo cache =
new ConcurrentHashMapClass? extends Resource,
AnnotationInfo();
Then you don't need getAnnotationDescriptors. You probably want
a way to clear cache entries if a class is reloaded, say.
You could get more fancy, with Futures and such, but I think
that would be wasted effort.
--tim
On Tue, Apr 7, 2009 at 1:20 PM, Tal Liron tal.li...@threecrickets.com
wrote:
Ah, I can see your point now.
I would recommend, then, that a Context would have two separate
ConcurrentHashMaps, something like this:
1. Context.getConfiguration() -- this would be for the user
2. Context.getImplementationCache() -- this would be for things like
AnnotationUtils, and the user should not normally look at this, except
perhaps for debugging
-Tal
David Fogel wrote:
Hi Tal-
I think what you suggested about appending a classloader id (perhaps
System.identityHashCode(cl) ?) would work.
Regarding the Restlet Context and this cache being "cruft": You say
the Context is a reasonable place for information that applies to the
Application, but this doesn't have annotation cache doesn't have
anything to do with my Application, it's related to a hidden
_implementation_ detail. As an end-user, we're not meant to be using
this annotion info cache directly. Yet the Context, as a very
prominent and unavoidable part of the Restlet public API is meant to
be used and understood. That's why I think it isn't a good place to
stash implementation-related data like this annotation stuff.
-Dave
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1572499
Re: Annotations and Restlet's future
Hi Rémi, Will annotations in restlet the advertised way of creating restlet application ? I moved to Restlet 1.2 M2/snapshot without using annotations. I found no reason why these annotations will help me. Everything works fine without annotations and I think/hope Restlet won't force us to use them in the near future. Best regards, Lars -- http://www.semagia.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1600565
Google AppEngine and Restlet
Hi all, Just out of curiosity: Has someone tried Google AppEngine [1] together with Restlet (Servlet connector)? [1] http://code.google.com/intl/de/appengine/docs/java/gettingstarted/ Best regards, Lars -- http://www.semagia.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1601014
Re: Annotations and Restlet's future
I would agree with that as a guide (and I think it is what Jerome has in mind) ... the annotations are nice for people who like them. It seems Jerome is striving for something very terse that supplants boilerplate in a number of common cases, which I can see is a nice goal. But if annotations were ever *required* to get things done, it would cause some real problems for me. On Wed, Apr 8, 2009 at 2:58 PM, Lars Heuer he...@semagia.com wrote: I moved to Restlet 1.2 M2/snapshot without using annotations. I found no reason why these annotations will help me. Everything works fine without annotations and I think/hope Restlet won't force us to use them in the near future. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1601018
Re: Google AppEngine and Restlet
Wow: Please share your experience, especially in your approach of data structure in document-based AppEngine using JDO and JSON for data transport from GWT and GAE. BaTien DBGROUPS and Budhnet On Wed, 2009-04-08 at 15:29 -0400, Rob Heittman wrote: :: smiling :: Gosh, it's been available all day ... I'm sure someone has tried it out by now ... We'll be experimenting with it heavily between now and Google I/O at end of May -- we already have a lite version of our Restlet-based GoGoEgo CMS engine that runs on the Python version of App Engine, and will be seeing what better stuff can be done with the Java version. If Restlet doesn't run well on the Java version of App Engine out of the box, I'm sure some of my team will want to work on portage ... :-) - R On Wed, Apr 8, 2009 at 3:23 PM, Lars Heuer he...@semagia.com wrote: Hi all, Just out of curiosity: Has someone tried Google AppEngine [1] together with Restlet (Servlet connector)? [1] http://code.google.com/intl/de/appengine/docs/java/gettingstarted/ Best regards, Lars -- http://www.semagia.com -- http://restlet.tigris.org/ds/viewMessage.do? dsForumId=4447dsMessageId=1601014 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1601660
Re: ServerResource conditional mode
Jerome, I understand If-Match, but I'm still confused by ServerResource's support of it in conditional mode. Logically, POST and PUT should work even if there is no entity, right? Right now, my GET returns an error status because there is no entity, but then I can't get POST/PUT to work while in conditional mode because of that. No entity, no possibility of checking conditions... which doesn't make sense to me. It seems to me that if GET doesn't return a value, then POST and PUT should continue as normal in conditional mode. Could the problem be that I'm setting an error status? But, then, I do need to set an error status for true failures of GET... I'm still confused! -Tal Jerome Louvel wrote: Hi Tal, The conditional mode is here to support HTTP conditional methods as explained for the "If-Match" header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24 The idea is that before executing some methods (PUT, POST, etc.), it is possible to check whether the resource state has changed (tag or date comparison). This check has to be done on the entity that would have been returned by an equivalentGET. So we have to simulate a GET in order to check conditions, whatever is the actual method handled. Now, there is no reason to simulate the GET if the client hasn't expressed any condition. I have fixed ServerResource#doConditionalHandle() so it will work fine in your cases. Just note that if your client do express some conditions, the ServerResource will expect your subclasses to provide support for GET or else it will result in an error. I think this is reasonable and you can always turn off conditional processing if you really don't want to provide GET implementation. Hope this clarifies. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder~ http://www.noelios.com De: Tal Liron [mailto:tal.li...@threecrickets.com] Envoy: jeudi 2 avril 2009 23:20 : discuss@restlet.tigris.org Objet: ServerResource conditional mode Hi, Does someone have a grasp on what conditional mode is for and how it used? It's enabled by default, but I had to disable it for one of my resources to work with PUT and POST. The issue is that it always calls doGetInfo first, which for my particular resource will fail, and so calls to PUT and POST also fail. Also, it seems to me that calling doGetInfo for every request, even for methods that are not GET, is wasteful. In short, I simply don't understand why this check happens, and subsequently what exactly conditional mode is doing. :) -Tal
Re: ServerResource conditional mode
Jerome, regarding exceptions caught -- You've implemented this only for when users override methods in non-annotated mode. In annotated mode, exceptions are still not allowed. This leads to different ways of doing things if you're in annotated or non-annotated mode. Personally, I think that disallowing exceptions across the board would result in better user code. If you decide that you do want to handle exceptions for annotated handlers, see doHandle(AnnotationInfo): you would need to get the reflected exception via InvocationTargetException.getTargetException(). Whatever you decide, I recommend that the same allowances be made for both annotated and non-annotated mode. -Tal Jerome Louvel wrote: 2) Exceptions caught Currently (SVN trunk at least), the ResourceExceptions are caught and the response status is updated accordingly. This is done in the ServerResource#handle() method. Other exceptions will be caught upper in the processing chain, by the StatusService for example. We do have some plans to extend the ConverterService in order to automatically convert common exceptions into matching statuses, but I'm not clear yet whether this is such a good idea (JAX-RS has this).
Re: 1.1.4 isn't in maven.restlet.org
Ah sweet - for some reason I completely glossed over that sentence on the page. Cheers. mark On Wed, Apr 8, 2009 at 8:47 PM, Thierry Boileau thierry.boil...@noelios.com wrote: Hello Mark, not at all, this is not a manual process. As written here [1], the public repository is updated twice a month on the 1st and the 15th of april. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1603095
Re: [1.1.3] Tomcat + RestletFrameworkServlet mapping SpringBeanRouter to /
Hi Paul,
On Apr 8, 2009, at 10:18 AM, Paul Austin wrote:
Jerome,
Here is an implementation which extends SpringBeanRouter, it could
easily be integrated into the super class.
Thanks for the suggestion. I've added something similar in
SpringBeanRouter in trunk r4711, but I only added an attachments
property (a la SpringRouter).
Reasoning: I don't think that setAttachment makes sense as a bean
property, since it is actually adding another attachment instead of
replacing anything. Restlet's main Router class also has the concept
of a default restlet. The semantics in Router are a bit different
than what you have here (its default is the restlet that receives all
requests that don't map to something else, not the top-level resource
-- depending on the routing mode these might be different things), so
I left it out. You should still be able to map the top-level route
using the attachments property like so:
property name=attachments
map
entry key=valuetopLevelResource/value/entry
/map
/property
I haven't tried this, though, so if it doesn't work please let me
know. (We can come up with a different property name if necessary.)
Thanks again,
Rhett
import java.util.Map;
import java.util.Map.Entry;
import org.restlet.Finder;
import org.restlet.ext.spring.SpringBeanRouter;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
public class SpringRouter extends SpringBeanRouter implements
BeanFactoryAware {
private BeanFactory beanFactory;
public void setAttachment(String uriPattern, String beanName) {
Finder finder = createFinder(beanFactory, beanName);
attach(uriPattern, finder);
}
public void setAttachments(MapString, String attachments) {
for (EntryString, String attachment : attachments.entrySet()) {
String uriPattern = attachment.getKey();
String beanName = attachment.getValue();
setAttachment(uriPattern, beanName);
}
}
public void setBeanFactory(BeanFactory beanFactory) throws
BeansException {
this.beanFactory = beanFactory;
}
public void setDefaultAttachment(String beanName) {
String uriPattern = ;
setAttachment(uriPattern, beanName);
}
}
Paul
On Wed, Apr 8, 2009 at 4:12 AM, Jerome Louvel jerome.lou...@noelios.com
wrote:
Paul,
The problem is that the URI without the trailing slash isn't
equivalent to the one with it. It's true that in many cases, people
assume it is equivalent but it doesn't have to.
Also, relative URIs can be expressed in the same way if the ends
with a slash or not, leading to further routing issues. The only way
we found to clean that is to force the client to redirect itself to
the URI with a slash. However, it isn't something we should do
automatically.
BTW, there is a related RFE:
Improve matching of directory URIs
http://restlet.tigris.org/issues/show_bug.cgi?id=532
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
De : Paul Austin [mailto:mail-li...@revolsys.com]
Envoyé : mardi 7 avril 2009 21:58
À : discuss@restlet.tigris.org
Objet : Re: [1.1.3] Tomcat + RestletFrameworkServlet mapping
SpringBeanRouter to /
Here is a class which fixes the issue. Probably a better solution
would be to change the Route class so that if the remainingPart is
it sets it to / before doing the regex matching. On a related
note is it possible to force exact matching so that say /apps would
be mapped but not /apps/xyz?
public class RootSpringBeanRouter extends SpringBeanRouter {
@Override
public void handle(Request request, Response response) {
Reference resourceRef = request.getResourceRef();
if (resourceRef.getRemainingPart().equals()) {
resourceRef.addSegment();
}
super.handle(request, response);
}
}
On Tue, Apr 7, 2009 at 12:27 PM, Paul Austin mail-
li...@revolsys.com wrote:
In my project I am deploying an application as a war file. The root
of the web application /* is mapped to the RestletFrameworkServlet
so that all handling is performed by Restlet.
servlet
servlet-namebpf/servlet-name
servlet-
classcom.noelios.restlet.ext.spring.RestletFrameworkServlet/
servlet-class
/servlet
servlet-mapping
servlet-namebpf/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
The root restlet is a SpringBeanRouter and I have a mapping for / to
a resource as shown below.
bean id=root class=org.restlet.ext.spring.SpringBeanRouter /
bean
name=/
id=rootResource
scope=prototype
class=myResourceClass
/
The war is deployed to /ws on my server.
If I access /ws I get an Restlet status page error saying The
server has not found anything matching the request URI but if I
use /ws/ it works correctly.
I tried mapping to to see if that
Re: Annotations and Restlet's future
Jerome was on the JSR 311 expert group but Restlet doesn't support it? --Erik 2009/4/8 Rémi Dewitte r...@gide.net I can see that Jérôme has already answered a great deal of my questions in this thread :) http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334 Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1604346
Re: Annotations and Restlet's future
JAX-RS = JSR 311. JAX-RS is available as a Restlet extension. I'll point out one elephant in the room, though: the JAX-RS extension has not yet received the same level of attention as other Restlet extensions that were developed by the core Noelios team. Even the Restlet-GWT extension I lead was mainly ported by Jerome ... I just helped over implementation hurdles and provided concrete use cases and documentation. Anyway. The JAX-RS extension doesn't feel as finished as the core of the project, because it's not. This probably ain't right. Also: JAX-RS feels a lot to me like JPA. I can mark up any old POJO with annotations that brilliantly, even miraculously generate glue for a particular paradigm (REST or relational persistence). But, to me, either one still amounts to a very lovely, silver filigreed, impeccably wrought glue gun. If I'm writing RESTful web services, I want a thoroughly RESTful architecture surrounding me, dammit ... which is what Restlet provides. I want my Resources to know all about it and leverage it to the hilt. They are where the rubber meets the road; where the underlying system is modeled in a RESTful way. So I'm kind of like Lars here, a conscientious annotation objector :-) But I also think I see what Jerome is doing too -- providing annotations that aren't meant to be a generalized glue gun, but a way to straightforwardly tell Restlet things that might take a lot of boilerplate to do otherwise. This is a neat idea. It seems like it's not meant to be a generic RESTify your POJO mechanism -- which JAX-RS already is -- but a way to author Restlet Resources with less effort and perhaps even less pratfalls. I haven't played with it enough to know whether it fills that role effectively ... I may not get a chance before it's too late to really comment. The broader concern I have ... well, I vainly think I see the point of the new Resource annotations because I have become a hard core Restlet developer. Still, what does a newbie think? It's confusing to have two slightly different annotation systems in play at once. It looks like Restlet is taking on JAX-RS with an alternative, and the user must choose one. The message traffic seems to reflect this confusion is already happening. I think having a Restlet @Get(form) and a JAX-RS @GET is probably more confusion than a lot of folks can swallow. Hibernate seems to have played it well by heavily internalizing the JPA spec, using JPA where it fits, and providing custom annotations where it doesn't. Maybe wrapping JAX-RS in a tighter embrace and making it more core to Restlet is part of the solution. Or, to solve the confusion, it may be as simple as modulating the annotation names. I don't know: @ResourceGets(form) instead of @Get(form) or such. This would make clear that it's a Restlet thing and not an abstract standards-driven RESTful markup thing. Anyway ... my personal preference is to leave the darned things out entirely, so perhaps I oughtn't to be operating my keyboard to comment on this. I only like to use annotations for purely compile-time code management purposes (@ThreadSafe, @SuppressWarnings) and not really ever for functional purposes. Pass the boilerplate and a side of fries. - Rob On Wed, Apr 8, 2009 at 7:35 PM, Erik Beeson erik.bee...@gmail.com wrote: Jerome was on the JSR 311 expert group but Restlet doesn't support it? --Erik 2009/4/8 Rémi Dewitte r...@gide.net I can see that Jérôme has already answered a great deal of my questions in this thread :) http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334 Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1604945
Re: Annotations and Restlet's future
+1 I.e., what Rob said. Take care, John On Apr 8, 2009, at 17:15 , Rob Heittman wrote: JAX-RS = JSR 311. JAX-RS is available as a Restlet extension. I'll point out one elephant in the room, though: the JAX-RS extension has not yet received the same level of attention as other Restlet extensions that were developed by the core Noelios team. Even the Restlet-GWT extension I lead was mainly ported by Jerome ... I just helped over implementation hurdles and provided concrete use cases and documentation. Anyway. The JAX-RS extension doesn't feel as finished as the core of the project, because it's not. This probably ain't right. Also: JAX-RS feels a lot to me like JPA. I can mark up any old POJO with annotations that brilliantly, even miraculously generate glue for a particular paradigm (REST or relational persistence). But, to me, either one still amounts to a very lovely, silver filigreed, impeccably wrought glue gun. If I'm writing RESTful web services, I want a thoroughly RESTful architecture surrounding me, dammit ... which is what Restlet provides. I want my Resources to know all about it and leverage it to the hilt. They are where the rubber meets the road; where the underlying system is modeled in a RESTful way. So I'm kind of like Lars here, a conscientious annotation objector :-) But I also think I see what Jerome is doing too -- providing annotations that aren't meant to be a generalized glue gun, but a way to straightforwardly tell Restlet things that might take a lot of boilerplate to do otherwise. This is a neat idea. It seems like it's not meant to be a generic RESTify your POJO mechanism -- which JAX-RS already is -- but a way to author Restlet Resources with less effort and perhaps even less pratfalls. I haven't played with it enough to know whether it fills that role effectively ... I may not get a chance before it's too late to really comment. The broader concern I have ... well, I vainly think I see the point of the new Resource annotations because I have become a hard core Restlet developer. Still, what does a newbie think? It's confusing to have two slightly different annotation systems in play at once. It looks like Restlet is taking on JAX-RS with an alternative, and the user must choose one. The message traffic seems to reflect this confusion is already happening. I think having a Restlet @Get(form) and a JAX-RS @GET is probably more confusion than a lot of folks can swallow. Hibernate seems to have played it well by heavily internalizing the JPA spec, using JPA where it fits, and providing custom annotations where it doesn't. Maybe wrapping JAX-RS in a tighter embrace and making it more core to Restlet is part of the solution. Or, to solve the confusion, it may be as simple as modulating the annotation names. I don't know: @ResourceGets(form) instead of @Get(form) or such. This would make clear that it's a Restlet thing and not an abstract standards-driven RESTful markup thing. Anyway ... my personal preference is to leave the darned things out entirely, so perhaps I oughtn't to be operating my keyboard to comment on this. I only like to use annotations for purely compile- time code management purposes (@ThreadSafe, @SuppressWarnings) and not really ever for functional purposes. Pass the boilerplate and a side of fries. - Rob On Wed, Apr 8, 2009 at 7:35 PM, Erik Beeson erik.bee...@gmail.com wrote: Jerome was on the JSR 311 expert group but Restlet doesn't support it? --Erik 2009/4/8 Rémi Dewitte r...@gide.net I can see that Jérôme has already answered a great deal of my questions in this thread :) http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334 Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1606738
Re: Annotations and Restlet's future
Nicely
put, Rob.
I
have to agree in the general sense. I'd even add that annotations are
one of the most abused features in Java, and I often regret their
introduction into the language. For every problem solved elegantly with
an annotation, you'd find ten solutions made worse. Sometimes, I even
miss the days where everything was turned into an XML configuration.
I've seen JEE projects mixing JSF, Spring and other annotation-based
data frameworks until methods accumulated ten different annotations!
How does that help anyone?
Part
of why I prefer Java, as a language, to other languages in the C family
is that it doesn't have things like operator overriding or hidden
finalizers or magic run-time type information handling. In Java, you
always can tell immediately what methods are being called in a section
of code. Compare with C++ or C# where a section of code might have
hidden method calls that aren't apparent without a very smartly
colorizing IDE. C++ is probably the most easy-to-abuse language for
this reason.
But
let's focus on the very specific use for annotations in the case of
ServerResource: they save you from writing your own switching method.
Without annotations, you would have to override a method (actually,
you'd need to override several at the moment -- the non-annotated
ServerResource is still a bit of a mess right now), do your own
checking of variants or whatever, and from there call the appropriate
method. The annotations handle that boilerplate code for you.
The
rule of thumb for good annotations, as far as I'm concerned, is that
you can look at the annotation and still in your mind clearly see what
the boilerplate code would look like. The moment you get into magical
"it just works" mechanisms, I turn into Rob. :) POJOs magically
serializing themselves into databases or flying about as part of EJB
transactions sounds nice until the first bug appears. And then you
would give your left leg for regular, non-generic, procedural code you
can look at with your own two eyes.
As
it stands, ServerResource annotations are just at about the tipping
point for me. There are two different modes supported in the background
(negotiated and conditional) in addition to annotated vs.
non-annotated, and I honestly have no clue what goes on unless I step
slowly with the debugger.
Jerome,
I'm sure things will get a lot clearer as we reach the 1.2 release.
But, you did ask for feedback, so here it is. Java developers are a
skeptical bunch. If we believed in magic, we'd be programming in Ruby.
;)
-Tal
Rob Heittman wrote:
JAX-RS = JSR 311. JAX-RS is available as a Restlet
extension.
I'll point out one elephant in the room, though: the JAX-RS
extension has not yet received the same level of attention as other
Restlet extensions that were developed by the core Noelios team. Even
the Restlet-GWT extension I lead was mainly ported by Jerome ... I just
helped over implementation hurdles and provided concrete use cases and
documentation. Anyway. The JAX-RS extension doesn't feel as
"finished" as the core of the project, because it's not. This probably
ain't right.
Also: JAX-RS feels a lot to me like JPA. I can mark up any old
POJO with annotations that brilliantly, even miraculously generate glue
for a particular paradigm (REST or relational persistence). But, to
me, either one still amounts to a very lovely, silver filigreed,
impeccably wrought glue gun.
If I'm writing RESTful web services, I want a thoroughly RESTful
architecture surrounding me, dammit ... which is what Restlet provides.
I want my Resources to know all about it and leverage it to the hilt.
They are where the rubber meets the road; where the underlying system
is modeled in a RESTful way.
So I'm kind of like Lars here, a conscientious annotation
objector :-) But I also think I see what Jerome is doing too --
providing annotations that aren't meant to be a generalized glue gun,
but a way to straightforwardly tell Restlet things that might take a
lot of boilerplate to do otherwise. This is a neat idea. It seems
like it's not meant to be a generic "RESTify your POJO" mechanism --
which JAX-RS already is -- but a way to author Restlet Resources with
less effort and perhaps even less pratfalls. I haven't played with it
enough to know whether it fills that role effectively ... I may not get
a chance before it's too late to really comment.
The broader concern I have ... well, I vainly think I see the
point of the new Resource annotations because I have become a hard core
Restlet developer. Still, what does a newbie think? It's confusing to
have two slightly different annotation systems in play at once. It
looks like Restlet is taking on JAX-RS with an alternative, and the
user must choose one. The message traffic seems to reflect this
confusion is already happening. I think having a Restlet @Get("form")
and a JAX-RS @GET is probably more confusion than a lot of folks can
swallow.
Re: Restlet and Large PUT requests
Hi, I would look at Chunked Transfer as described in the HTTP spec. Does anyone know if Restlet supports this? Regards Donald. Stephan Koops stephan.ko...@we b.de To Sent by: discuss@restlet.tigris.org stephan.ko...@web cc .de Subject Re: Restlet and Large PUT requests 08/04/09 02:17 AM Please respond to discuss disc...@restlet. tigris.org Hi, because it seems to me, you get no answer until now, here a possibility: You use the representation, and write into or write from its InputStream / Reader. best regards Stephan webp...@tigris.org schrieb: Greetings, I am new to Restlet and am not sure how to solve this problem, or if Restlet is capable of doing what I am after: I need to be able to generate a PUT request that has a large (500mb+) amount of text. The text its self is generated on the fly (not from a file on disk). I then need to be able to have a Restlet server that accepts this large PUT request without having to read the entire request into memory first (I currently plan on streaming it back out to a physical file). Anyone have any ideas on how to do the above using the Restlet client/server libraries? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1545862 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1579466 ** Any personal or sensitive information contained in this email and attachments must be handled in accordance with the Victorian Information Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988 (Commonwealth), as applicable. This email, including all attachments, is confidential. If you are not the intended recipient, you must not disclose, distribute, copy or use the information contained in this email or attachments. Any confidentiality or privilege is not waived or lost because this email has been sent to you in error. If you have received it in error, please let us know by reply email, delete it from your system and destroy any copies. ** -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1606982
Re: Annotations and Restlet's future
Hi All- Well, I almost can't believe I'm saying this, but I'd like to weigh in on the side of considering Annotation-based approaches to writing resources in Restlet. (Although I'm not so sure about Jerome's current plan.) I've mostly disliked, and sometimes despised, the use of Annotations in most of the places I've encountered them, for many of the same reasons some of you have mentioned. I don't like the way they're used in hibernate and JPA (predicting what will happen with those annotated classes is difficult), I was initially excited by the idea of all-java config in google's Guice framework until I realized what my classes would look like with all the annotations. And I don't even really like the simple @Override convention for labeling methods (I figure the tools could probably figure it out without the annotation). But a few months ago I forced myself to read through the JX-RS spec in a fit of due-diligence, while at the same time going through the process of re-familiarizing myself with the state of the Restlet project, which I hadn't looked at since before 1.1. And it modified my thoughts on annotations. (It turns out the JAX-RS spec is unusually short and comprehensible, which is unusual for these enterprisey specs. The downside is that it's short partly because they left out a little too much, and JAX-RS is essentially not a stand-alone technology, you pretty much need some sort of injection container around it, which the spec ignores, and therefore there's effectively no way to write portable jax-rs code for any application that does anything interesting, like accessing stored data, for instance.) Both Restlet and Jax-RS provide a framework for implementing conceptual resources as sets of handler methods on a java class. From the perspective of the resource class author, these handler methods are the main public api of your class- routing happens somewhere else in the container. Additionally, both Restlet and JAX-RS recommend that these Resource instances be per-request in scope, so they really don't have much of a lifecycle, or many reciprocal interactions with other parts of the application. By the time any of the custom handler methods get called, all the routing and much of the details of the HTTP protocol have been taken care of by the container. The main difference between JAX-RS and Restlet is that JAX-RS puts as much of the code to handle the content negotiation and other protocol issues into the container (and so alllows its Resource classes to be superclass-less POJOs), while Restlet puts this code into the mandated Resource (now ServerResource) base-classes, where it is more accessible and allows greater customization. Anyhow, my point is that the main challenge seems to me to be in sorting out which of the handler methods should get called. And this ends up being all about metadata- the metadata of the conceptual Resource combining with the metadata attached to the HTTP requests. And one problem for people trying to automate the mapping of requests onto java methods is that, until recently, java methods didn't provide much in the way of places to stick data about themselves. I am personally guilty of having written frameworks that resorted to method naming patterns as a way around this, and it's, well, not elegant. But if there's one appropriate use of Annotations it might be to add data _about_ methods, specifically _public_ methods. (The reason I don't like seeing annotations used to decorate private member fields is that these fields are supposed to be private, hidden implementation details, not something for outside things to mess around with.) There's really no way of getting around the need to associate some data (like text/html) with some handler method. And if you don't use annotations to do this, then you have to capture that association in what becomes effectively routing code. I did a number of experiments comparing how to implement the same resources in Restlet and in Jax-RS, and for the most part the only difference was the presence of this routing code in the Restlet version, which got replaced by a couple of easy-to-understand annotations. So, to sum up what has been a much-too-long post, I'm convinced that it's desireable to attempt to replace the unavoidable writing of routing code with annotations on target methods, as long as the annotations are clear, self-explanatory, and don't try to hide too much magic. -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1609318
