Thread-safety in Guard

2007-10-03 Thread Tim Peierls
There is a serious thread-safety problem in org.restlet.Guard (Restlet 1.0.5). The secrets field is lazily initialized without proper synchronization and the TreeMap used to initialize it is not thread-safehttp://java.sun.com/javase/6/docs/api/java/util/TreeMap.html. The simplest fix would be to

Re: Thread-safety in Guard

2007-10-06 Thread Tim Peierls
). Leaving them non-final is not correct. --Tim Peierls

Re: Thread-safety in Guard

2007-10-06 Thread Tim Peierls
in Practicehttp://jcip.netby Brian Goetz, Josh Bloch, Joe Bowbeer, David Holmes, Doug Lea, and me (Tim Peierls). My recommendation is probably biased by the fact that I helped write it, but we've had a lot of good feedback. --tim

Re: Thread-safety in Guard

2007-10-09 Thread Tim Peierls
On 10/9/07, Jerome Louvel [EMAIL PROTECTED] wrote: Good idea, I've entered a RFE for this documentation task: http://restlet.tigris.org/issues/show_bug.cgi?id=369 What's the best way for me (or anyone else) to report other concurrency and documentation issues that I encounter? In this

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-16 Thread Tim Peierls
In this case, as with a subsequent message from Jim Alateras, the problem appears to be that the representation size exceeds the capacity of the underlying pipe (1024), and no one is reading from the input stream side of the pipe. But who made these daemon threads? Mixing blocking data structures

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-16 Thread Tim Peierls
On 10/16/07, J. Matthew Pryor [EMAIL PROTECTED] wrote: The thread is created by the ByteUtils class in its getStream() method Yes, but what are you doing with the InputStream returned by getStream()? I suspect that you aren't reading this stream completely, so the writing thread blocks

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-17 Thread Tim Peierls
On 10/17/07, Jerome Louvel [EMAIL PROTECTED] wrote: In terms of end to end functionality, our use of GZip encoding works fine and the encoded representations make it from client to server OK, so the concern is simply that there end up being hundreds of these dead corpse threads left over

Re: Thread-safety in Guard

2007-11-05 Thread Tim Peierls
On 11/4/07, Jerome Louvel [EMAIL PROTECTED] wrote: I've fixed the remaining Guard.secrets issue following Tim advises: - removed the setSecrets() method in trunk - eagerly instantiate the secrets map I've also fixed potential issues with RouteList using an underlying

Re: Testing strategies

2007-11-20 Thread Tim Peierls
On Nov 20, 2007 9:06 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Interfaces are useful in published APIs when they contain a very small and stable set of methods that you know won't need to expand. Agreed. A good example is the java.lang.Comparable interface. A counter example is the List

Re: Testing strategies

2007-11-20 Thread Tim Peierls
On Nov 20, 2007 1:55 PM, Sean Landis [EMAIL PROTECTED] wrote: Stated differently, maybe when the convergence is over, it will be much safer to move to interfaces. The nearly immutable nature of interfaces won't be such an issue since the API questions will have mostly been answered. And

Re: Exceptions in general

2007-11-28 Thread Tim Peierls
On Nov 28, 2007 5:38 AM, Stephan Koops [EMAIL PROTECTED] wrote: I agree fully with Paul. Exceptions are the modern way to handle things, that don't are the normal way. The same thing should be possible for doPut(..), doGet(..), getRepresentation(.) and so on on subclasses of

Re: Exceptions in general

2007-11-29 Thread Tim Peierls
On Nov 29, 2007 10:57 AM, Rob Heittman [EMAIL PROTECTED] wrote: Hmmm. I feel myself spiraling back to the interfaces vs classes question. Don't go into the light! :-) Isn't this just more evidence that it's very hard to specify interfaces in unstable APIs? But now you've got me thinking.

Re: Lightweight alternative to Reference

2007-11-29 Thread Tim Peierls
On Nov 29, 2007 7:58 PM, Paul J. Lucas [EMAIL PROTECTED] wrote: On Nov 29, 2007, at 4:52 PM, Tim Peierls wrote: Abstractly, though, would you rather see ReferenceBuilderException checked or unchecked in the following: try { Reference ref = ReferenceBuilder.appendBar (myBar

Re: Lightweight alternative to Reference

2007-11-29 Thread Tim Peierls
Order dependence is fine if the fluent interface verbs imply ordering (appendXXX) rather than not (setXXX). But some of the parts of a URI are order-independent (e.g., scheme), even if others are not (e.g., path component). I see no reason to impose an order on the order-independent parts.

Re: A Restlet interface to Subversion?

2007-12-03 Thread Tim Peierls
On Dec 3, 2007 5:27 PM, Jerome Louvel [EMAIL PROTECTED] wrote: If you are using Restlet trunk (future 1.1), you should override the new methods: - acceptRepresentation(Representation entity) for POST - setModifiable(boolean modifiable) for PUT What happened to storeRepresentation? -

Re: Lightweight alternative to Reference

2007-12-04 Thread Tim Peierls
On Dec 4, 2007 9:50 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Again, if the performance isn't an issue, we could simply implement the methods this way (+ NPE checks) : public void addQueryParameter(String name, String value) { setQuery(getQuery() + '' + encode(name) + '=' +

Re: Thread safety policies of high level objects

2007-12-14 Thread Tim Peierls
On Dec 14, 2007 2:15 PM, Rob Heittman [EMAIL PROTECTED] wrote: Did we ever come up with a definitive list of which high level Restlet objects are expected to be thread-safe and which are not? I thought so, but could not find it on the list. I wanted to add some JCIP concurrency annotations

Re: ServerServlet broken by concurrency fix in 1.1M1

2007-12-28 Thread Tim Peierls
I think it's easier to reason about the correctness when protocols is final. Note that with that patch there is a race condition in setProtocols; for example, two calls to setProtocols with different lists might end up with the concatenation of the two lists, rather than one or the other. I don't

Re: ServerServlet broken by concurrency fix in 1.1M1

2007-12-29 Thread Tim Peierls
On Dec 29, 2007 7:46 AM, Jerome Louvel [EMAIL PROTECTED] wrote: I've applied Tim's patch to the trunk. The List returned by getProtocols is the actual CopyOnWriteArrayList itself, safe for access (including modification) by multiple threads. Is that what you want? (Just making sure, not saying

Re: Restlets and Asynchronous Request Processing

2008-01-24 Thread Tim Peierls
On Jan 23, 2008 7:04 PM, Rob Heittman [EMAIL PROTECTED] wrote: Getting full value out of asynchronous calls will clearly involve a lot of careful work across the RI and extensions. It would be a great opportunity to apply correct and modern Java concurrency patterns -- I hope Tim Peierls

Re: Adding Cookies to a Client Request

2008-02-03 Thread Tim Peierls
On Feb 3, 2008 2:59 PM, William Pietri [EMAIL PROTECTED] wrote: Because of this, returning a collection can mean one of four things: 1. I'm giving you my copy of the data; please don't change it (return foo). 2. I'm giving you my copy of the data; you may change it (return foo). 3.

Re: Evaluating Restlet

2008-02-05 Thread Tim Peierls
On Feb 5, 2008 3:38 AM, Jerome Louvel [EMAIL PROTECTED] wrote: However, they can't leverage NIO from the socket to the Servlet as the Servlet API has no provision for NIO as explained above. This is where the Restlet API makes the difference, by introducing the Representation class based on

Re: Confusion with filter

2008-02-22 Thread Tim Peierls
Thierry, I'm curious: Why is createRoot() synchronized? --tim On Fri, Feb 22, 2008 at 2:18 PM, Thierry Boileau [EMAIL PROTECTED] wrote: Hi Chris, assuming that you you are using an application like that : public class YourApplication extends Application { @Override public

Re: Response Object Threadpool issue

2008-02-27 Thread Tim Peierls
On Wed, Feb 27, 2008 at 8:36 AM, Tim Peierls [EMAIL PROTECTED] wrote: Currently RESTlet doesn't support asynchronous handling of requests, so the only way to use thread pools is to submit tasks from the response handling thread and block until the tasks. That should have read ... until

Re: Response Object Threadpool issue

2008-02-27 Thread Tim Peierls
is a good summary of the issues. --tim On Wed, Feb 27, 2008 at 8:47 AM, code dude [EMAIL PROTECTED] wrote: Thanks Tim ...What About servlet response in Jetty or Tomcat ...do they support asynchronous handling of requests?? , can this be overcome thru callbacks ?? On 2/27/08, Tim Peierls

Re: Series.getValues()

2008-03-27 Thread Tim Peierls
ListParameter doesn't seem like the right abstraction, even when provided as Series. Parameters seem more akin to a multimap than to a sequence of key-value pairs. And for the (many?) users who don't take advantage of the multiplicity they are closer to regular maps. If sequence of keys is

Re: Evaluating Restlet

2008-04-03 Thread Tim Peierls
to synchronize access to the those fields whenever the invariant might temporarily be invalidated. --tim On Tue, Apr 1, 2008 at 3:42 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Tim Peierls wrote: I hate to sound like a broken record, but the Restlet Request and Response classes are not thread-safe

Re: Evaluating Restlet

2008-04-05 Thread Tim Peierls
On Sat, Apr 5, 2008 at 5:07 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Thanks for the suggestion about the safe double-check idiom, very cool. As Request/Response have many optional property and as those are very frequently created objects, I think we should ready try to keep lazy

Re: First resource page

2008-04-09 Thread Tim Peierls
This is a nice bit of documentation by example -- I'm glad you added it. FirstResourceApplication is not thread-safe, however. I know you want the example to be simple, but it's important to give readers code that exemplifies good practice. This is different from using an in-memory Map instead of

Re: Guards and authentication mechanisms

2008-06-04 Thread Tim Peierls
On Wed, Jun 4, 2008 at 9:00 AM, Bruno Harbulot [EMAIL PROTECTED] wrote: What I'm less clear about is the benefits of the double-check locking (DLC) pattern. I think the intent behind this pattern was to improve performance, but was in fact broken until the Java 5 memory model (and the use of

Re: Restlet causing JVM crashes

2008-06-09 Thread Tim Peierls
Yet another reason to prefer immutable classes: less likely to trigger Hotspot bugs. --tim On Mon, Jun 9, 2008 at 8:12 AM, Kevin Conaway [EMAIL PROTECTED] wrote: Hi Mark, I had the same problem as you. I tweaked some lines of code in that class and recompiled and the issue went away. It

Re: Guards and authentication mechanisms

2008-06-10 Thread Tim Peierls
On Tue, Jun 10, 2008 at 4:37 AM, Bruno Harbulot [EMAIL PROTECTED] wrote: Thank you for all these details. I was a bit confused, because in Java Concurrency in Practice, you don't seem very fond of the double-check idiom (even when volatile is used). Yeah ... sorry about the confusion. *Java

Re: 1.1m4 release notes --- Added a static “current” property to...

2008-06-19 Thread Tim Peierls
While it's nice to have the static current() methods to get around limitations imposed by existing code, I'm a little worried that they might become an over-used crutch that would break once asynchronous handling is introduced. Is there a way to word the javadocs to discourage their use more

Re: Calling wait() in a handleGet in a Resource, blocks all other requests?

2008-06-21 Thread Tim Peierls
On Fri, Jun 20, 2008 at 10:14 PM, Guillermo Cantu [EMAIL PROTECTED] wrote: My problem is that I need a pool manager to control the number of instances of a 3rd party library that are loaded to service the requests. Each request needs an instance of the 3rd party library. So let's say I can

Re: Calling wait() in a handleGet in a Resource, blocks all other requests?

2008-06-21 Thread Tim Peierls
On Sat, Jun 21, 2008 at 9:35 AM, Tim Peierls [EMAIL PROTECTED] wrote: While it's currently true of Restlet that each Resource instance is confined to a single thread, this may change in the future, so it would be unwise to rely too heavily on it. Getting a litle OT, here's a utility that can

Re: 1.1m4 release notes --- Added a static current property to...

2008-07-02 Thread Tim Peierls
On Wed, Jun 25, 2008 at 4:26 AM, Jerome Louvel [EMAIL PROTECTED] wrote: In order to ensure that the methods still work when invoked by another thread, the engine could keep a copy of those thread local variables are restore them on the new thread when calling again the Restlet code. For

Re: 1.1m4 release notes --- Added a static

2008-07-05 Thread Tim Peierls
On Fri, Jul 4, 2008 at 6:33 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Tim, instead of wrapping the submitted tasks with thread-local copy/reset code, I've chosen to use the ability to provide a ThreadFactory to the Executors static creation method. Do you see any drawback compared to your

Re: 1.1m4 release notes --- Added a static

2008-07-10 Thread Tim Peierls
On Thu, Jul 10, 2008 at 4:16 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Thanks for pointing to this issue, I went too fast here. I've just checked in SVN trunk the fix, following your suggestions. Note that in the execute(Runnable) method, I've replaced execute(new Runnable() by

Re: Unwanted removal of attribute suffix in Tomcat environment

2008-07-13 Thread Tim Peierls
If the HashMap you were using was shared by multiple threads without appropriate synchronization, that might explain why you had problems in that setting but not with constant values. --tim On Sun, Jul 13, 2008 at 9:22 AM, Lutz Harder [EMAIL PROTECTED] wrote: Hello Thierry, I have finally

some volatile fields could be final

2008-07-22 Thread Tim Peierls
Not sure whether this is worthy of a separate issue or just something to add to an existing concurrency issue, but I just noticed that com.noelios.restlet.http.StreamServerHelper has two volatile ExecutorService fields and a volatile CountDownLatch field that could easily be turned into final

Re: 1.1m4 release notes --- Added a static

2008-07-23 Thread Tim Peierls
:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de* Tim Peierls *Envoyé :* jeudi 10 juillet 2008 18:05 *À :* discuss@restlet.tigris.org *Objet :* Re: 1.1m4 release notes --- Added a static On Thu, Jul 10, 2008 at 4:16 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Thanks for pointing

Injecting Restlet resources with Guice

2008-07-24 Thread Tim Peierls
I wrote up a progress report on my use of Guice to inject Restlet resources. http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html Nothing earth-shaking, but it makes Restlet application programming a tad more comfortable for me. --tim

Re: ExecutorService (Was: 1.1m4 release notes)

2008-07-29 Thread Tim Peierls
] [mailto:[EMAIL PROTECTED] *De la part de* Tim Peierls *Envoyé :* vendredi 25 juillet 2008 18:04 *À :* discuss@restlet.tigris.org *Objet :* Re: 1.1m4 release notes --- Added a static On Fri, Jul 25, 2008 at 11:32 AM, Jerome Louvel [EMAIL PROTECTED] wrote: Something that worries me it that we

Re: ExecutorService (Was: 1.1m4 release notes)

2008-07-30 Thread Tim Peierls
make sure to pass the ExecutorService a ThreadFactory which names Thread appropriately? Having descriptive thread names is extremely helpful when using jconsole or viewing thread dumps. Thanks, Kevin On Tue, Jul 29, 2008 at 8:17 PM, Tim Peierls [EMAIL PROTECTED] wrote: Jerome, Seems like

Re: ExecutorService (Was: 1.1m4 release notes)

2008-08-03 Thread Tim Peierls
helpful when using jconsole or viewing thread dumps. Thanks, Kevin On Tue, Jul 29, 2008 at 8:17 PM, Tim Peierls [EMAIL PROTECTED] wrote: Jerome, Seems like you're going to a lot of trouble to duplicate existing functionality -- I think all one really needs is a way to wrap existing

Re: ExecutorService (Was: 1.1m4 release notes)

2008-08-03 Thread Tim Peierls
ExecutorService between calls to stop()/start(). I'll try to think of something else, though... --tim On Sun, Aug 3, 2008 at 12:52 PM, Tim Peierls [EMAIL PROTECTED] wrote: Jerome, I just noticed that to compile TaskService with Java 6 successfully, the Collection arguments to invokeAny

Re: ExecutorService (Was: 1.1m4 release notes)

2008-08-04 Thread Tim Peierls
On Sun, Aug 3, 2008 at 1:16 PM, Tim Peierls [EMAIL PROTECTED] wrote: I think the easiest thing to do is to give up on having TaskService implement ExecutorService and instead give it a method that returns the (wrapped) ExecutorService and add documentation warning users not to stash

Re: ExecutorService (Was: 1.1m4 release notes)

2008-08-04 Thread Tim Peierls
it sounds? Best regards, Jerome -- *De :* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de* Tim Peierls *Envoyé :* lundi 4 août 2008 16:23 *À :* discuss@restlet.tigris.org *Objet :* Re: ExecutorService (Was: 1.1m4 release notes) On Sun, Aug 3, 2008

Re: Guice and 1.1m5

2008-08-13 Thread Tim Peierls
Tim Peierls' excellent tutorial on using Guice in Restlets (found at http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html) and found that, while it works quite well with 1.1m4, it does not work with 1.1m5. The error seems to be in the Guice Provider for the Context

Re: Guice and 1.1m5

2008-08-14 Thread Tim Peierls
will be returned anymore. Tim Peierls wrote: Chris, I managed to get some slightly less limited connectivity out here in the Maine woods. When you do discover what changes between m4 and m5 caused Context.getContext() to return null in m5, I think it might be a good idea to change

Re: Guice and 1.1m5

2008-08-20 Thread Tim Peierls
developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -- *De :* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de* Tim Peierls *Envoyé :* lundi 18 août 2008 20:50 *À :* discuss@restlet.tigris.org *Objet :* Re

Re: Using the standalone server

2008-09-30 Thread Tim Peierls
On Tue, Sep 30, 2008 at 5:55 PM, Rob Heittman [EMAIL PROTECTED]wrote: P.S. Since Restlet doesn't do it on its own yet, here's my browser identity cookie generator: http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java Thanks for

Re: Using the standalone server

2008-09-30 Thread Tim Peierls
Yes. In *Java Concurrency in Practice* lingo, you need to be able to declare of any non-final, non-volatile field f that is potentially accessed by multiple threads that f is @GuardedBy(something), where something is usually this for non-static fields, but could be any object, like the referent of

Re: Using the standalone server

2008-09-30 Thread Tim Peierls
complicated than counting) I could have declared a random Object lockObject and the block would be functional, at least. /threadjack - R On Tue, Sep 30, 2008 at 8:30 PM, Tim Peierls [EMAIL PROTECTED] wrote: In this case, though, the value of the field incr is changing, so it is not suitable

Re: Using the standalone server

2008-10-01 Thread Tim Peierls
On Wed, Oct 1, 2008 at 9:12 AM, Rob Heittman [EMAIL PROTECTED]wrote: As some folks found the CookieUtility class useful outside GPL context, I updated trunk to dedicate it to the public domain. Improvements/suggestions are welcome, maybe to inform a future Restlet feature along these lines.

Re: Using the standalone server

2008-10-01 Thread Tim Peierls
On Wed, Oct 1, 2008 at 10:10 AM, Tim Peierls [EMAIL PROTECTED] wrote: Also, the range of lincr is not 0 .. 2^31, even without concurrency problems, since at least one value Integer.MAX_VALUE is always allowed. Oops, the range *is* 0 .. 2^31, just not 0 .. Integer.MAX_VALUE. --tim

Re: XmlRepresentation.internalEval

2008-10-14 Thread Tim Peierls
On Tue, Oct 14, 2008 at 2:41 PM, Jerome Louvel [EMAIL PROTECTED]wrote: For the 'final' keyword usage, it might save a bit of memory at most. No big gain here I suspect. How would memory be saved? Are there really compilers that generate different bytecode depending on the presence of the

Re: XmlRepresentation.internalEval

2008-10-14 Thread Tim Peierls
know! Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -- *De :* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de* Tim Peierls *Envoyé :* mardi 14

Re: XmlRepresentation.internalEval

2008-10-14 Thread Tim Peierls
It's not a huge deal, but superfluous final keywords are clutter that distract from the places where final is being used meaningfully. I think it's worth cleaning this up incrementally in Restlet. --tim On Tue, Oct 14, 2008 at 4:28 PM, Rob Heittman [EMAIL PROTECTED]wrote: A bit of troglodytic

Re: Assistance and Question

2008-10-16 Thread Tim Peierls
On Thu, Oct 16, 2008 at 4:57 PM, Rob Heittman [EMAIL PROTECTED]wrote: Pragmatically, our applications do reuse Client instances in production code and have not had any trouble with this. It's meant to be thread safe. Tim points out a valid thread safety issue, but it's not likely to cause

Re: Restlet governance

2008-10-22 Thread Tim Peierls
Typo in that change: s/by/but/ in we not only consider you as a user by as a potential contributor. --tim On Wed, Oct 22, 2008 at 3:59 PM, Jerome Louvel [EMAIL PROTECTED]wrote: Hi Steve, I fully agree and updated both the governance document and the welcome message on the user guide:

Re: Problem with Url redirection

2008-11-03 Thread Tim Peierls
On Mon, Nov 3, 2008 at 1:43 PM, Thierry Boileau [EMAIL PROTECTED] wrote: NB: for a complete list of supported predefined variables:

Re: Restlet MVC

2008-11-21 Thread Tim Peierls
Maybe the first line of that FAQ answer should be modified to avoid the word implementation, e.g., There is a rough correspondence between the MVC pattern [cite?] and the Restlet framework: --tim On Fri, Nov 21, 2008 at 9:18 AM, Avi Flax [EMAIL PROTECTED] wrote: Bravo, Rob! I agree 100%! FYI,

Re: securing Restlet

2008-12-26 Thread Tim Peierls
On Fri, Dec 26, 2008 at 5:05 AM, Jerome Louvel jerome.lou...@noelios.comwrote: Also, Rob Heittman previously a CookieUtility class to the public domain: http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java There is a race condition

Re: Restlets and Asynchronous Request Processing

2009-01-07 Thread Tim Peierls
Jérôme, Could you elaborate on your most recent comments in the Support asynchronous processing issue? http://restlet.tigris.org/issues/show_bug.cgi?id=143 In particular, what would the Response autoSent property mean? --tim

Re: Command line to STOP Restlet server

2009-01-13 Thread Tim Peierls
Take a look at Java Service Wrapper: http://wrapper.tanukisoftware.org/ It covers all sorts of possibilities. --tim On Mon, Jan 12, 2009 at 12:29 PM, Leshek lesh...@hotmail.com wrote: I want to have stop and exit restlet server command line interface. The start is simple (java -jar

Re: media type adaptor

2009-01-16 Thread Tim Peierls
While this is undeniably convenient, it deserves more thought and discussion before accepting as part of 1.2. I don't think it's a good idea as it stands. Item 35 of Josh Bloch's Effective Java (2nd edition) is Prefer annotations to naming patterns. One of the great strengths of Java is its

Re: media type adaptor

2009-01-21 Thread Tim Peierls
! Best regards, Jérôme 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é :* vendredi 16

Re: media type adaptor

2009-01-26 Thread Tim Peierls
Tim, I didn't follow the ful discussion, but did you take a look to JAX-RS? best regards Stephan Tim Peierls schrieb: So, if we are back using runtime annotations, there is no particular type safety in play: Representation representXml(); would be as good

Re: WadlApplication and Guice in Restlet 1.1.1 problem with Finder.createTarget(Class? extends Handler...)

2009-02-03 Thread Tim Peierls
for finder.createTarget(Class? extends Handler, Request, Response) to be public, I would suggest that it be demoted, and that WadlApplication be changed simple to use finder.findTarget(request, response). Here is further analysis of why this fails with the Guice version, and a workaround for Tim Peierls

Re: How to integrate jetty's ThrottlingFilter

2009-02-06 Thread Tim Peierls
Henry, A few problems with this code: - Postdecrement of a volatile is not atomic. - Calls to foreign code in a synchronized block risks deadlock. - As you suspected, there is no guarantee that afterHandle will be called once for every call to beforeHandle. Here's an untested,

Re: Warning: References are not immutable!

2009-02-09 Thread Tim Peierls
Although I certainly agree in principle that it is vastly preferable to work with immutable objects where possible, in this case I don't see a strong need to change Reference or even to add an ImmutableReference type, since it's easy to convert to and from an existing immutable type, java.net.URI.

New resource API design

2009-02-18 Thread Tim Peierls
On Wed, Feb 18, 2009 at 12:09 PM, Jerome Louvel jerome.lou...@noelios.comwrote: Did you have a chance to check the updated resource API design? http://wiki.restlet.org/developers/172-restlet/226-restlet.html It looks good to me. My only concern is that in the attempt to be consistent with

Re: Generic URI pattern and Resource

2009-02-27 Thread Tim Peierls
You could do this by defining a custom Finder that creates an instance of a Resource of the appropriate subclass of Asset, assetType, given the request URI /Asset/{assetType}/{id}. But is it really necessary to have a resource type hierarchy that directly mirrors your business domain? Why not

Re: Is org.restlet.Client thread safe?

2009-03-16 Thread Tim Peierls
Yes, or at least the most recent version of it in the trunk is. But I just noticed that that version unnecessarily declares the helper field as volatile when it could be final. Jerome, Thierry -- could you enter an issue for this? I'm having trouble wrangling the issue tracker. --tim On Sun, Mar

Re: Resource factories

2009-03-20 Thread Tim Peierls
I tried to solve this problem in a limited way, using Guice, and wrote about it here: http://tembrel.blogspot.com/2008/07/resource-dependency-injection-in.html Maybe some of this could adapted for your purposes. --tim On Fri, Mar 20, 2009 at 10:03 PM, Tal Liron tal.li...@threecrickets.comwrote:

Re: Resource factories

2009-03-24 Thread Tim Peierls
I had almost finished drafting a response, but as usual Rob said it all better than I could. Let me emphasize that construction of short-lived objects like Resources is going to be much faster and less error-prone than managing state shared across multiple requests. Doug Lea has said that if you

Re: Restlet 1.2 M2 released

2009-04-02 Thread Tim Peierls
On Thu, Apr 2, 2009 at 12:13 PM, Rhett Sutphin rh...@detailedbalance.netwrote: On Apr 2, 2009, at 11:11 AM, Stephan Koops wrote: Jonathan Hall schrieb: Shame you can't have @Get(MediaType.TEXT_HTML). I don't know. Would it work to change MediaType from class to an enum? That could work,

Comments on First Resource article (Restlet 1.2m2)

2009-04-05 Thread Tim Peierls
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

Re: Comments on First Resource article (Restlet 1.2m2)

2009-04-06 Thread Tim Peierls
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

Re: ServerResource is currently incompatible with OSGi

2009-04-08 Thread Tim Peierls
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) {

Re: Comments on First Resource article (Restlet 1.2m2)

2009-04-08 Thread Tim Peierls
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)

Re: Resource factories

2009-04-08 Thread Tim Peierls
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

Re: Annotations and Restlet's future

2009-04-09 Thread Tim Peierls
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

Re: ServerResource is currently incompatible with OSGi

2009-04-09 Thread Tim Peierls
...@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

Re: ServerResource is currently incompatible with OSGi

2009-04-09 Thread Tim Peierls
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

Re: Restlet 1.2 M2 released

2009-04-09 Thread Tim Peierls
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

Re: Annotations and Restlet's future

2009-04-09 Thread Tim Peierls
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

Re: ServerResource is currently incompatible with OSGi

2009-04-12 Thread Tim Peierls
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

Re: CRUD Items pattern

2009-04-22 Thread Tim Peierls
The Restlet introductory material is excellent but it could spend more time emphasizing that Resource classes are not (usually) the domain objects but rather the means for mapping the RESTful world into domain objects. If that mapping is similar across several domain types, as Rob says is often

Re: Restlet 1.2 to become Restlet 2.0

2009-05-06 Thread Tim Peierls
The assignment of issues to milestones seems odd, but maybe this was true before the 1.2 - 2.0 renaming: Why are all the defects associated with 2.0M4 and not 2.0M3? I was hoping to be able to develop a Restlet 1.2-based system over the next 5-6 months and put it into production at the end of the

Dependency injection in Restlet 2.0 with Guice

2009-05-12 Thread Tim Peierls
I just posted a short article on my blog about using Guice with Restlet 2.0. http://tembrel.blogspot.com/2009/05/dependency-injection-in-restlet-20-with.html Not much new here, just updated to work with ServerResource. (Still supports Handler, but not for long if Handler is going away.) I had

Re: Dependency injection in Restlet 2.0 with Guice

2009-05-14 Thread Tim Peierls
On Thu, May 14, 2009 at 3:10 PM, Jerome Louvel jerome.lou...@noelios.comwrote: By the way, do you think it would be technically possible to develop a similar integration that would leverage the recently announced “javax.inject”? http://crazybob.org/2009/05/announcing-javaxinjectinject.html

Re: Dependency injection in Restlet 2.0 with Guice

2009-05-17 Thread Tim Peierls
~ 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é :* jeudi 14 mai 2009 21:53 *À :* discuss@restlet.tigris.org *Objet :* Re: Dependency

Re: Cookie based authentication

2009-05-19 Thread Tim Peierls
the performance loss by using a synchronized(this) to read two fields. I was initially using a single secretKey field of type SecretKey. I may suggest a patch to actual restlet CryptoUtils to support it. Thanks for your insight ! Rémi On Tue, May 19, 2009 at 07:09, Tim Peierls t...@peierls.net wrote

Re: Dependency injection in Restlet 2.0 with Guice

2009-06-03 Thread Tim Peierls
On Sun, May 31, 2009 at 12:17 PM, Jerome Louvel jerome.lou...@noelios.comwrote: So, I’ve just granted you SVN commit rights. I suggest that we first create a module “org.restlet.ext.guice” in the incubator part of SVN, see details here: I created some basic files and directories by copying

Re: Guidance on Atom/APP in Restlet

2009-07-17 Thread Tim Peierls
at 2:32 PM, Tim Peierls t...@peierls.net wrote: Some rambling newbie Restlet design questions: Background: I'm in the preliminary stages of a ground-up redesign of an existing non-Restlet application. I'm (naturally) convinced that Restlet is the way to go for this redesign, and I'm pretty sure I

Re: Guidance on Atom/APP in Restlet

2009-07-20 Thread Tim Peierls
, I was working on Atom stuff back around 1.2 milestone 4 or so, and at that time I found it easiest to use ROME to offer up feed representations instead of the Restlet Atom extension, so I can't say much about what would work best now. On Fri, Jul 17, 2009 at 2:32 PM, Tim Peierls t

Re: Guidance on Atom/APP in Restlet

2009-07-21 Thread Tim Peierls
not just Atom+XML, but manages to adhere to fundamental principles of APP. Aside from Google's own proprietary auth mechanism (which I think can be replaced with Oauth for general masses), I think Google's use of GData/APP is a good example of APP in the real world. On 7/18/09, Tim Peierls t

Re: Guidance on Atom/APP in Restlet

2009-07-21 Thread Tim Peierls
On Tue, Jul 21, 2009 at 4:39 AM, Jerome Louvel jerome.lou...@noelios.comwrote: However, for communication with GWT, it is indeed a better idea to rely on JSON. I have also been working on reusing the 'transparent' serialization of beans between Restlet/Server and Restlet/GWT. This

  1   2   3   4   >