Re: Annotations and Restlet's future
Good treatment, Dave, not too long :-) I do agree with your thoughts generally ... except to harp on my only *strong* requirement, that the annotation based solution must remain a voluntary choice and not the only way to get things done. It should remain possible to achieve whatever annotations can achieve in a non-annotation way. This allows the basic API outline to work in places where annotations are not available or work differently enough to cause friction (pre-1.5 JVM backports, GWT, API ports to other languages, Scala ...) It is OK with me if the non-annotation approach requires verbosity or heavy lifting, it just needs to exist. I can indeed see the benefit of writing many Resources more economically and intelligently with the right annotations ... and I also think, used consistently, this could help with my little dream of producing a machine and human readable REST interface specification that gives a large chunk of the enterprise value of WADL and WSDL without any of the associated misery. 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. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1611242
Re: Restlet 1.2 M2 released [throw previous email away]
Why not making it optional ? As for me, I quite like extension names and would keep it enabled because it makes uri comprehensives. Examples http://server/path/resource?media=xml http://server/path/resource?media=json http://server/path/resource?media=xls Easy to guess or try the others for an end user. Cheers, Rémi On Wed, Apr 8, 2009 at 19:52, Tal Liron tal.li...@threecrickets.com wrote: 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.comtal.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
HttpAmazonS3Helper
Can someone give me an example on how to use the HttpAmazonS3Helper class? Thanks in advance, Matt -- View this message in context: http://n2.nabble.com/HttpAmazonS3Helper-tp2609388p2609388.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1608094
Re: Annotations and Restlet's future
On Wed, Apr 8, 2009 at 8:15 PM, Rob Heittman rob.heitt...@solertium.comwrote: 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. Or @Accepts, @Stores, and friends, from the 1.1 method names. I could go either way. The risk that @Get will be confused with @GET is there, but I'd hate to be bullied out of the space. --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1607097
RE: Weird issue with VirtualHosts
Hi Jerome, Shortly after posting that I realized we had a couple of DNS/reverse proxy issues. Now that's been sorted it's working fine. Sorry to have wasted your time, Matt 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 -- View this message in context: http://n2.nabble.com/Weird-issue-with-VirtualHosts-tp2603116p2609196.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1606857
Re: [1.1.3] Tomcat + RestletFrameworkServlet mapping SpringBeanRouter to /
Rhett,
I agree on the setAttachment semantics. I'd still like to see
something like the setDefaultAttachment method (e.g. setNoPath
attachment) without using the setAttachments method as it is a lot
simpler to configure. For all other cases the current router works fine.
Another option would be where you could specify a more regular
expresssion like pattern. You could then match this case using ^$ as
the path (i.e beginning and end of line with no content or to match /
and it would be ^/?$? Not sure how we'd get the template params in
there as java regex doesn't allow you to name groups of matches.
Paul
On 8-Apr-09, at 4:18 PM, Rhett Sutphin wrote:
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-
Re: ServerResource is currently incompatible with OSGi
Did you read my subsequent e-mail that talked about opening an issue to make
this more robust?
There is currently no standard concurrent map with weak keys, although
MapMaker in Google Collections provides this and much more. An effort to put
something like this into Java 7 is under way, but there's no telling whether
it will actually happen.
Wrapping a WeakHashMap with synchronization is likely to be a performance
bottleneck: every request has to grab a global lock.
--tim
On Wed, Apr 8, 2009 at 2:06 PM, Tal Liron tal.li...@threecrickets.comwrote:
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 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.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=1602917
RE: How to Fetch Request XML in Java Restlet
Hi Jerome, Can you please be more specific?? I alerady looked at the below link which you provided, but I still couldn't understand which part exactly accepts the request XML. My request XML would be in following format: customerinfo fnameTest/fname lnameFoo/lname /customerinfo Now, I need to accept this input parse it using some parser then sent the response back in XML format. Which part of the code is actually accepting the input which method is fetching it? Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1600348
Re: ServerResource is currently incompatible with OSGi
On Wed, Apr 8, 2009 at 9:42 AM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi all, Beautiful! This new solution is available in SVN trunk. Thanks Dave for the report and Tim for the clever fix! You're welcome. ;-) This fix will do for now, but it could be made more robust. Having strong references to the Class objects makes me uncomfortable: what if these resource classes are being generated dynamically for one shot uses? They'll never go away. I suggest creating an issue to track alternative implementations. For example, Google Collections has a MapMaker class that would make it trivial to implement a much more robust solution. --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1598681
Re: Restlet 1.2 M2 released
Jerome, I like the compactness of what you are proposing. My concern is orthogonal to this, however, and I apologize if I'm making too much of a fuss over this one point: Relying exclusively on string values in annotations raises the possibility of spelling errors that are not detected at compile time and might in fact not be detected at all. In a complex system, the fact that one URI isn't generating or accepting exactly the set of representations you thought it did might go unnoticed for a very long time. Providing String constants would cut down on a lot of errors, but you still want users to be able to roll their own combinations, and the minute they do that, all bets are off. I threw out a few ideas of a how one might use enum and/or class values instead of strings as annotation parameters, but I only scratched the surface. I'm sure it would be possible to devise a scheme where those who wanted the compile-time checking could get it, and those who didn't could use the compact string formulations. Another approach that might appeal to you more is to use annotation processors to examine the string values at compile-time to parse and validate them against a registry of known elements that would also be built by annotation processors. Those who don't care about such things could happily skip the annotation processor step and just trust that their spelling is right. Those who do care would get compile-time validation. --tim On Tue, Apr 7, 2009 at 12:48 PM, Jerome Louvel jerome.lou...@noelios.comwrote: What I would like to be able to do is express potentially complex variants with a compact syntax as annotation values. By complex variants, I mean variants like JSON and UTF-8 and English-US or like JSON or XML, and English-US or French-FR. The design that I'd like to implement for 1.2 M3 is based on extension names solely and a couple of operators: - '|' for a logical OR (ex: application/json or text/xml = json|xml) - '*' for the cartesian product between variant dimensions (ex: json|xml * en|fr) - '+' for a logical AND (ex: JSON and UTF-8 = json+utf8) - ':' to separate return variant from input parameter entity characteristics You can find a bit more details on this page, paragraph Annotation parameter: http://wiki.restlet.org/developers/172-restlet/226-restlet.html Also, it isn't allowed to use full media types values such as text/xml as it would potentially conflict with our variants grammar and lead to very verbose values. Otherwise, I'm considering adding an Extension class that would contain String constants for various extensions declared by default in the MetadataService: - Extension.EN : en - English language - Extension.XML : xml - text/xml media type - Extension.CSS : css - etc. Would that design be a good balance between all our design concerns/goals? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1598602
RE: How to Fetch Request XML in Java Restlet
Hi Jerome, Thanks for the reply. I looked at the below URL already but still I'm not clear couldn't find it. Can you please be more specific tell me which Java file which method are you referring to exactly? What I'm really looking for is something like the below request XML would be an input for the web service. person fnameGavinfname lnameFoo/lname person Now, webservice should accept this input xml then do processing send back the results back in XML format. But how do I exactly read the above request XML? Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1601093
Re: Annotations and Restlet's future
On Thu, Apr 9, 2009 at 4:57 AM, Rob Heittman rob.heitt...@solertium.comwrote: ...my only *strong* requirement, that the annotation based solution must remain a voluntary choice and not the only way to get things done. It should remain possible to achieve whatever annotations can achieve in a non-annotation way. This allows the basic API outline to work in places where annotations are not available or work differently enough to cause friction (pre-1.5 JVM backports, GWT, API ports to other languages, Scala ...) It is OK with me if the non-annotation approach requires verbosity or heavy lifting, it just needs to exist. Isn't that currently the case with the 1.2 branch? (Does GWT not support annotations yet? I thought it did.) It would be best if the non-annotation approach used the same terminology as the annotations, and I think that's not the case right now. --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1612961
Re: Annotations and Restlet's future
It seems like I'm the only one here working with non-annotated ServerResources right now, so I'd chime in and add that you actually need to override more than method for each REST method as it stands. There's get(), get(variant), post(entity), post(entity, variant), put(entity), put(entity, variant), delete(), delete(variant). Also, all these methods are allowed to throw ResourceExceptions, but annotated handlers cannot. So, it at stands, non-annotated and annotated mode are currently very different. Also, it seems that annotated mode is turned on by default, and that you have to explicitly turn it off in doInit(). I'm sure some of us would prefer this to be the other way around! Or perhaps automatic detection of some sort? -Tal Tim Peierls wrote: On Thu, Apr 9, 2009 at 4:57 AM, Rob Heittman rob.heitt...@solertium.com wrote: ...my only *strong* requirement, that the annotation based solution must remain a voluntary choice and not the only way to get things done. It should remain possible to achieve whatever annotations can achieve in a non-annotation way. This allows the basic API outline to work in places where annotations are not available or work differently enough to cause friction (pre-1.5 JVM backports, GWT, API ports to other languages, Scala ...) It is OK with me if the non-annotation approach requires verbosity or heavy lifting, it just needs to exist. Isn't that currently the case with the 1.2 branch? (Does GWT not support annotations yet? I thought it did.) It would be best if the non-annotation approach used the same terminology as the annotations, and I think that's not the case right now. --tim
Re: Comments against Restlet 1.2M2
Hi all, [...] Some comments against that release: [...] I like to add another point: Rename ServerResource#isExists to isExisting(). isExists hurts me. ;) It would make sense to rename setExists(boolean) as well. Best regards, Lars -- http://www.semagia.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1617653
Re: ServerResource is currently incompatible with OSGi
Oh, I didn't mean synchronizing the whole map. I
actually didn't mean much beyond suggesting that we brainstorm a way to
use WeakReferences as keys in this particular case. I still don't have
a complete solution in mind.
Another idea: Perhaps we can use a ReentrantReadWrite lock around a
simple WeakHashMap? Since this is a "99% read" situation, most requests
won't need to acquire locks.
(ConcurrentHashMap is actually a very
complicated and delicately tuned class, and it would be anything but
trivial for us to try to re-implement it using WeakReferences.)
I know there are generic 3rd party solutions to this, but I know we'd
all prefer to use what Java 5 offers us right now. I'm sure we can
cobble together something that performs well!
-Tal
Tim Peierls wrote:
Did you read my subsequent e-mail that talked about
opening an issue to make this more robust?
There is currently no standard concurrent map with weak keys,
although MapMaker in Google Collections provides this and much more. An
effort to put something like this into Java 7 is under way, but there's
no telling whether it will actually happen.
Wrapping a WeakHashMap with synchronization is likely to be a
performance bottleneck: every request has to grab a global lock.
--tim
On Wed, Apr 8, 2009 at 2:06 PM, Tal Liron tal.li...@threecrickets.com
wrote:
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
Re: Restlet 1.2 M2 released [throw previous email away]
Oops,
sorry Remi, I didn't mean to imply that I'd want to disable the way
TunnelService works, only to imply that perhaps we should call these
strings it uses something else, something that's not mixed up with
filename extensions, and have it in a registry separate from the
Extensions.
This
conversation has been a bit too academic so far, so I'm posting below
the complete list of extensions in MetadataService, so that you can see
some of the problems I'm referring to. Some highlights:
1.
Check out the Extension "xml" -- it refers to both MediaType.TEXT_XML
and MediaType.APPLICATION_XML. This is an example of a one-to-many
connection, which is of course the de-facto existence for filename
extensions, but in situations when we need to refer to a specific MIME
type, it's not clear what the result would be. In annotations and in
TunnelService would "xml" imply both MIME types? How could we refer to
specifically to one? (I assume there is an answer to these questions,
I'm just uncomfortable that we even have to ask.)
2.
Check out "mp2", "mp3", "mp4". The first two are MediaType.AUDIO_MPEG
(many-to-one connection), the last is MediaType.VIDEO_MP4. Why this
confusion? It has to do with the social history of how these formats
were distributed. But, unless we look this up in the source code for
MetadataService, we wouldn't know.
3.
Check out the line for "txt" -- it actually uses a specialized method
of addExtension with an extra argument, that marks this as the
"preferred" extension. Again, this has to do with the one-to-many
issue. Confusing and irrelevant in the case of TunnelService or
ServerResource annotations.
4.
Sometimes filename extensions get a bit obscure. For example, "ai",
"eps" and "ps" all refer to MediaType.APPLICATION_POSTSCRIPT. Wouldn't
it be clearer to use the full string "postscript" for TunnelService and
for annotations? The mixing of uses here puts us in the awkward
position of accepting whatever the application designers chose to use
as a filename extension, which has to do with the limitations of FAT (3
character extensions), a crowded space of applications vying for
elegant 3-character extensions, etc. For either TunnelService or
annotations, I don't see why we need to adhere to that.
In
conclusion, I really hope we can agree on a simple one-to-one registry
of shortcuts for MIME types, for those cases when we need to refer to a
specific MIME type. And, if I had it my way, the full MIME type string
would also be acceptable in all such situations, though I won't be too
upset if this doesn't happen, as long as there's a one-to-one
relationship and I can be 100% clear about what MediaType is referred
to in any particular case.
(The
work that MetadataService does for handling filename extensions is fine
and should be kept as it is -- the situation there is indeed
complicated. I'm talking about an additional registry to handle
annotations and TunnelService.)
-Tal
addExtension("en", Language.ENGLISH);
addExtension("es", Language.SPANISH);
addExtension("fr", Language.FRENCH);
addExtension("ai", MediaType.APPLICATION_POSTSCRIPT);
addExtension("atom", MediaType.APPLICATION_ATOM);
addExtension("au", MediaType.AUDIO_BASIC);
addExtension("bin", MediaType.APPLICATION_OCTET_STREAM);
addExtension("bmp", MediaType.IMAGE_BMP);
addExtension("class", MediaType.APPLICATION_JAVA);
addExtension("css", MediaType.TEXT_CSS);
addExtension("csv", MediaType.TEXT_CSV);
addExtension("dat", MediaType.TEXT_DAT);
addExtension("dib", MediaType.IMAGE_BMP);
addExtension("doc", MediaType.APPLICATION_WORD);
addExtension("docm", MediaType.APPLICATION_MSOFFICE_DOCM);
addExtension("docx", MediaType.APPLICATION_MSOFFICE_DOCX);
addExtension("dotm", MediaType.APPLICATION_MSOFFICE_DOTM);
addExtension("dotx", MediaType.APPLICATION_MSOFFICE_DOTX);
addExtension("dtd", MediaType.APPLICATION_XML_DTD);
addExtension("eps", MediaType.APPLICATION_POSTSCRIPT);
addExtension("exe", MediaType.APPLICATION_OCTET_STREAM);
addExtension("fmt", Encoding.FREEMARKER);
addExtension("form", MediaType.APPLICATION_WWW_FORM);
addExtension("gif", MediaType.IMAGE_GIF);
addExtension("hqx", MediaType.APPLICATION_MAC_BINHEX40);
addExtension("htm", MediaType.TEXT_HTML);
addExtension("html", MediaType.TEXT_HTML);
addExtension("ico", MediaType.IMAGE_ICON);
addExtension("jad", MediaType.TEXT_J2ME_APP_DESCRIPTOR);
addExtension("jar", MediaType.APPLICATION_JAVA_ARCHIVE);
addExtension("java", MediaType.TEXT_PLAIN);
addExtension("jnlp", MediaType.APPLICATION_JNLP);
addExtension("jpe", MediaType.IMAGE_JPEG);
addExtension("jpeg", MediaType.IMAGE_JPEG);
addExtension("jpg", MediaType.IMAGE_JPEG);
addExtension("js", MediaType.APPLICATION_JAVASCRIPT);
FreeMarker Template Loading
Hello all, I'm running JDK 1.6 with Restlet 1.2 and the included FreeMarker all being served from a Tomcat 6 container. My FreeMarker templates are in the web content root under the directory freemarker-templates. I used to cast the context to a ServletContextAdapter before 1.2, and was able to tell my FreeMarker Configuration to obtain my Templates from the ServletContext, but that's not true anymore. Is there a way to get the ServletContext now? I am able to use this: getContext().getClientDispatcher().get(war:///freemarker-templates/ + templateName).getEntity(); and wrap it in a TemplateRepresentation, but my #include myHeader.ftl files within my templates no longer work as they're relative URLs. So which way is better? Is there a better third option? Thank you! Dustin -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | dustin.jenk...@nrc-cnrc.gc.ca facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1617986
Re: Annotations and Restlet's future
GWT 1.5/1.6 is happy with annotations at compile time ... but if the implementation needs to examine them at runtime via reflection, GWT doesn't have that capability. GWT getClass() emulation doesn't have getAnnotations() ... or much of anything else. There's no reflection in the Javascript room. Restlet 1.2's current incarnation is fine with me ... annotations optional. But I agree that the non-annotation and annotation approach should use the same vowels and consonants in the same order whenever possible :-) This helps us bears of very little brain. On Thu, Apr 9, 2009 at 7:06 AM, Tim Peierls t...@peierls.net wrote: On Thu, Apr 9, 2009 at 4:57 AM, Rob Heittman rob.heitt...@solertium.comwrote: ...my only *strong* requirement, that the annotation based solution must remain a voluntary choice and not the only way to get things done. It should remain possible to achieve whatever annotations can achieve in a non-annotation way. This allows the basic API outline to work in places where annotations are not available or work differently enough to cause friction (pre-1.5 JVM backports, GWT, API ports to other languages, Scala ...) It is OK with me if the non-annotation approach requires verbosity or heavy lifting, it just needs to exist. Isn't that currently the case with the 1.2 branch? (Does GWT not support annotations yet? I thought it did.) It would be best if the non-annotation approach used the same terminology as the annotations, and I think that's not the case right now. --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1618441
