Re: Authenticator for multiple authentication schemes

Not sure how much of this works in Restlet 2.1 -- I use CookieAuthenticator successfully with Restlet 2.2. On Thu, Jan 2, 2014 at 1:32 PM, Tim Peierls wrote: > It should be possible to chain two different Authenticator instances, with > optional = true on the first, and multiAuthenti

Re: Authenticator for multiple authentication schemes

stable Restlet 2.2... >> >> BTW, Restlet ppl, any idea on when 2.2 will become 'final'? The roadmap >> page on the Restlet website states Q3 2013... and that's about 3 months ago >> now... >> >> Thanks. >> >> >> On Thu, Jan 2, 2014

Re: Restlet, jackson and @JsonTypeInfo

One problem is that the generic type formal parameter T doesn't convey enough information for the annotation-based code to reconstruct the correct result type. Try creating a type that embeds the actual value of the type parameter, e.g., SiteDaoArrayList extends ArrayList (or SiteDaoArrayList conta

Re: Re: Restlet, jackson and @JsonTypeInfo

What arguments are you passing to @JsonTypeInfo? On Mon, Jan 27, 2014 at 6:57 AM, Jon Finanger wrote: > I'm trying to figure out how to get the android client to automatically > convert the representation into the correct Objecttype without using > mapper.convertValue(...) > > When looking at t

Re: RESTLET - chaining a validator and filter, why does it surpasses the filter?

On Tue, Mar 11, 2014 at 3:29 AM, saurabh narayan singh < cenasaur...@gmail.com> wrote: > I have a restlet in which i want to chain a validator and filter one after > the other in the code. The code goes something like this > > @Override > public synchronized Restlet createInboundRoot() > { > R

Re: How to : Different validation check for different mappings but same filter

On Wed, Mar 12, 2014 at 3:18 AM, saurabh narayan singh < cenasaur...@gmail.com> wrote: > I have multiple mappings in the restlet which are supposed to pass through > the same filter and authenticator, but for the different mappings i have to > use validationPresence(attribute) for different attrib

Re: How to : use System.out or logger in Restlet

The code in createInboundRoot is called once at application startup, so any logging in it is only called once. It sounds like you're trying to get logging each time a request is handled. For that you need to instrument the Restlets themselves, either in their handle() methods or in more specific m

Re: Dynamic Templates/Routing

You don't need to use Restlet ServerResource for this. You can write a custom Restlet with an initialization method that reads and caches the mapping from path to procedure, and a handle(Request, Resource) method that extracts path and parameters from the request and uses the cached mapping to call

Re: Re: Dynamic Templates/Routing

On Fri, Mar 28, 2014 at 9:48 AM, Tim wrote: > I'm wondering about your suggestion above, would I have to implement my > own code to match the templates and extract the parameters or could I take > advantage of the framework's ability to do that? > You could take advantage of the framework. Here'

Re: Re: Re: Dynamic Templates/Routing

Glad to hear it! Restlet isn't really doing much for you in this case, but at least this way you're in a perfect position to add new functionality or an alternative web API if the restrictions you currently operate under are ever lifted slightly. --tim On Mon, Mar 31, 2014 at 4:56 AM, Tim wrot

Re: Transparent reverse proxying using org.restlet.routing.Redirector

The code that does the header removal is here: https://github.com/restlet/restlet-framework-java/blob/2.2/modules/org.restlet/src/org/restlet/routing/Redirector.java#L405-L413 If you're confident that that's what you want, you can extend Redirector and override serverRedirect to do everything it

Re: Re: Transparent reverse proxying using org.restlet.routing.Redirector

I'm guessing you have to very selective about which headers you allow to remain. On Thu, Apr 17, 2014 at 3:08 PM, Primož Kokol wrote: > Tim, thanks for advice. > > That is actually one of the first things I've tried. > > After extending Redirector and overriding serverRedirect method so that >

Re: Re: Re: Transparent reverse proxying using org.restlet.routing.Redirector

I don't have time to look at this, unfortunately. I have Basic auth working with outbound redirection. I *don't *change the way the headers are removed, but I do remove the challenge response. // From my Redirector subclass: @Override protected void outboundServerRedirect(

Re: Shutdown via REST PUT request

You can call Component.stop() asynchronously with a delay, so that the PUT handler has a chance to complete. (Although I think POST captures the intent better: You're POSTing a request to shut down the component.) It could be as simple as this: @Post public String postShutdown(final String shutdo

Re: Transparent reverse proxying using org.restlet.routing.Redirector

Could this be addressed by turning off the DecoderService? There's no need to perform the decompression in the first place, is there? On Fri, Apr 25, 2014 at 8:13 AM, Arjohn Kampman < arjohn.kamp...@vound-software.com> wrote: > Hi Jerome, others, > > We've figured out what is going wrong by moni

Re: Re: Authenticator and Component XML configuration

On Wed, May 14, 2014 at 4:46 AM, Sergio wrote: > Can I attach the authenticator to only some of the methods of my > resources? I.e. protect only PUT, POST, and DELETE while keeping GET > public? Maybe using roles? > You can do per-resource or even per-method authorization: Remember that authenti

Re: Re: Authenticator and Component XML configuration

I don't think the nested router works the way you expect. You might be able to tweak it to work, but consider creating a separate authenticator (and tracer) instance for each guarded resource. I've written this up several times, but I can never find my old postings when I need them, so I've created

Re: How to remove URL form thread name?

I can find only two instances of ThreadFactory in the Restlet codebase, neither of which add a URL. The one in TaskService just replaces "pool" with "restlet" in whatever name the default factory uses. The LoggingThreadFactory uses the name "Restlet-XXX" where XXX is the hashcode of the thread bein

Re: Complexity in understanding

>From a brief look at your code, it looks like you're mixing up Restlets with ServerResources. Restlets are created and added to the routing structure in createInboundRoot, and typically have a lifetime that spans that of the application, while a new ServerResource instance is created for every req

Re: Complexity in understanding

Looks like you're attaching a vanilla Application instead of an instance of PageTest. On Thu, Aug 7, 2014 at 3:39 PM, Shai Levit wrote: > Hi Tim, > Thank for the insight and so I am working on adding more complexity. So > here > is a simple code that should work, but for some reason I get this

Re: Complexity in understanding

lder.toString(), > MediaType.TEXT_HTML)); > } > }; > > router.attach("", mainpage); > return router; > } > component.getDefaultHost().attach(application); > component.start(

Re: Using JUnit with JacksonRepresentation

Hard to be sure from what you've described, but it looks as though the entity doesn't contain anything. Try getting the raw contents of the entity in two places (1) before you post it and and (2) after you receive it but before you parse it by passing it to the JacksonRepresentation constructor. Do

Re: Re: Using JUnit with JacksonRepresentation

Sure sounds like that's the problem. For unit testing purposes, how about getting the text of representation, turning that into a StringRepresentation, and then constructing the JacksonRepresentation in terms of the StringRepresentation? It's wasteful, but it would allow you to proceed with your un

Re: "segment" router or subrouter

I think you can do better. Here's an old conversation that might have some hints: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2746996 Not all of this is relevant to you. Concentrate on the autowire part. --tim On Thu, Nov 20, 2014 at 11:01 AM, Koen Maes wrote: > Ok,

Trouble going from 2.2 to 2.3

The default connectors for various editions have changed between 2.2 and 2.3 (actually between 2.3-RC1 and 2.3.0). JEE edition no longer registers HTTP or HTTPS server helpers; JSE still does. Assuming this was intentional and not an oversight, the change causes problems for me. For several versio

Re: Trouble going from 2.2 to 2.3

der if we have >> to register these connectors by default, what is your thinking about that? >> >> And unfortunately, I won't be able to package a 2.3.1 release soon, I can >> achieve this on the 29th of December. >> >> >> Best regards, >> Thierry Boil

Re: Trouble going from 2.2 to 2.3

gt; -- > Thierry Boileau > > 2014-12-19 21:10 GMT+01:00 Tim Peierls : > >> I tried adding this line: >> >> Engine.getInstance().getRegisteredServers().add( >> new org.restlet.engine.connector.HttpServerHelper(null)); >> >> but it didn&

Re: CRUD Operation for Calling ServerResouce with ClientProxy

On Fri, Jan 16, 2015 at 5:20 AM, Thierry Boileau wrote: > Here is my first refactoring: > public class GaeThingServerResource extends SelfInjectingServerResource > implements ThingResource { > ... > @Override > public ThingItem doInit() { > id = Long.parseLong(getAttri

Thread-safety in Guard

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-safe. The simplest fix would be to

Re: Thread-safety in Guard

way is to make sure that they are accessed only while holding a synch lock (the same lock each time). Leaving them non-final is not correct. --Tim Peierls

Re: Thread-safety in Guard

should ask! I can highly recommend Java Concurrency in Practice<http://jcip.net>by 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

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 di

Re: HEAD not well supported?

On 10/11/07, Chuck Hinson <[EMAIL PROTECTED]> wrote: > > allowPut(), allowPost(), allowDelete(), allowGet() > > handlePut(), handlePost(), handleDelete(), handleGet() > > put(), post(), delete(), getRepresentation() - eh? what? > > The lack of symmetry there is jarring - it leads people to go looki

Re: EncodeRepresentation.write leaving blocked threads around?

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?

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 fore

Re: EncodeRepresentation.write leaving blocked threads around?

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

Re: Thread-safety in Guard

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 > CopyOnWrite

Re: Testing strategies

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

Re: Testing strategies

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

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 > org.restlet.

Re: Exceptions in general

Maybe I am -- but it would have been better if I had time to put together a concrete proposal. I don't. :-( --tim On Nov 28, 2007 8:42 AM, Stephan Koops <[EMAIL PROTECTED]> wrote: > Yes, you are right. > > greetings > Stephan > > Tim Peierls schrieb: > > On

Re: Exceptions in general

On Nov 29, 2007 2:31 AM, Sumit Lohia <[EMAIL PROTECTED]> wrote: > Rob Heittman solertium.com> writes: > > > In our current WebDAV and VFS stack, we have exception types that map > > straightforwardly to likely resource-related HTTP error status codes > > (NotFoundException, ConflictException...).

Re: Exceptions in general

On Nov 29, 2007 9:43 AM, Rob Heittman <[EMAIL PROTECTED]> wrote: > I'd defer to your expertise on the valid circumstances to use unchecked > exceptions, but I can see how Sumit's approach would get part of the way > without requiring breaking API changes. I think one could make Sumit's > solution

Re: Exceptions in general

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

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 { > > Refere

Re: Lightweight alternative to Reference

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. Abstrac

Re: A Restlet interface to Subversion?

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

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) + '=' + encode

Re: Thread safety policies of high level objects

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 > annotat

Re: ServerServlet broken by concurrency fix in 1.1M1

Does this patch fix it? Index: Connector.java === --- Connector.java(revision 2339) +++ Connector.java(working copy) @@ -44,7 +44,7 @@ */ public abstract class Connector extends Restlet { /** The list of protocols simu

Re: ServerServlet broken by concurrency fix in 1.1M1

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

On Dec 28, 2007 5:32 PM, Kevin Conaway <[EMAIL PROTECTED]> wrote: > I attached your patch to 368. Sure hope it works -- I didn't compile it or test it. :-( > setProtocols() could be renamed to addProtocols() with the > protocols.clear() call removed. > > That communicates the intention a litt

Re: ServerServlet broken by concurrency fix in 1.1M1

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 sayi

Re: ServerServlet broken by concurrency fix in 1.1M1

On Jan 2, 2008 4:57 PM, Jerome Louvel <[EMAIL PROTECTED]> wrote: > As I don't see any particular drawback, I would also prefer to mark the > method 'synchronized' for completeness purpose for this method and similar > ones. > That's fine -- but could you add a comment along the lines of "synchron

Re: ServerServlet broken by concurrency fix in 1.1M1

Thanks! An additional nice touch would be to make Component.hosts final, which would require moving its initialization outside the if statements in the constructor. Maybe some of the other fields, too? It's one less thing to worry about for these fields. --tim On Jan 3, 2008 4:22 PM, Jerome Louv

Re: Restlets and Asynchronous Request Processing

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 h

Re: Adding Cookies to a Client Request

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")

Re: Evaluating Restlet

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

Re: Confusion with filter

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

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. In addition, Request and Response objects are not thread-safe, so you have to manage access to them very carefully

Re: Response Object Threadpool issue

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

Re: Response Object Threadpool issue

post 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 ??

Re: File extensions to select variants

On Tue, Mar 18, 2008 at 4:57 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote: > The solution we are now considering is to enhance the TunnelService (one > for > each application) to support the automatic modification of the "Accept", > "Accept-Language", "Accept-Encoding", "Accept-Charset" headers (ac

Re: Series.getValues()

List 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 important, one co

Re: Evaluating Restlet

hen you need 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

Re: Evaluating Restlet

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 > initia

Re: First resource page

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: Custom Guard's authenticate not getting invoked

Does that mean that the tutorial for 1.1 is out of date in this section: http://www.restlet.org/documentation/1.1/tutorial#part09 "Note that the authentication and authorization decisions are fully customizable via the authenticate() and authorize() methods." ? --tim On Sat, Apr 19, 2008 at 7:

Re: Guards and authentication mechanisms

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

Re: Restlet causing JVM crashes

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.

Re: Guards and authentication mechanisms

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.

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

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 strong

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

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 s

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

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 lit

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

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. > > Fo

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

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

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 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 exec.e

Re: Hanging on ServerSocket.accept()

I came across the following discussion, which has a somewhat similar stack trace: http://groups.google.com/group/jets3t-users/browse_thread/thread/7fc0609b67aca645?fwc=1 Is it possible that javax.swing.filechooser.FileSystemView is designed only to be called from the event dispatch thread? That w

Re: Unwanted removal of attribute suffix in Tomcat environment

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 finall

some volatile fields could be final

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 field

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

ll suggested changes, including doc update. > > Thanks Tim! > > Best regards, > Jerome > ------ > *De :* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de* Tim > Peierls > *Envoyé :* jeudi 10 juillet 2008 18:05 > *À :* discuss@restlet.tigris.org > *O

Injecting Restlet resources with Guice

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: 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 should be able to stop and restart an > application, therefore we should be able to shutdown the thread pool then > restart it, which doesn't seem possible. We will probably have to re

Re: ExecutorService (Was: 1.1m4 release notes)

ppear here in about one hour: > http://www.restlet.org/documentation/snapshot/api/ > > Best regards, > Jerome > > > -- > *De :* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de* Tim > Peierls > *Envoyé :* vendredi 25 juillet 2008 18:04 > *À :* discuss@restlet.tigr

Re: ExecutorService (Was: 1.1m4 release notes)

let 2008 04:11 > *À :* discuss@restlet.tigris.org > *Objet :* Re: ExecutorService (Was: 1.1m4 release notes) > > Whichever way you end up going, can you make sure to pass the > ExecutorService a ThreadFactory which names Thread appropriately? > > Having descriptive thread

Re: ExecutorService (Was: 1.1m4 release notes)

gt;> Jerome >> >> >> -- >> *De :* Kevin Conaway [mailto:[EMAIL PROTECTED] >> *Envoyé :* mercredi 30 juillet 2008 04:11 >> *À :* discuss@restlet.tigris.org >> *Objet :* Re: ExecutorService (Was: 1.1m4 release notes) >> >>

Re: ExecutorService (Was: 1.1m4 release notes)

e returned 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 > Coll

Re: ExecutorService (Was: 1.1m4 release notes)

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

Re: ExecutorService (Was: 1.1m4 release notes)

ill require Java 6, we can then > reintroduce the generified signatures. How does 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 > *À

Re: Guice and 1.1m5

rd Context provision code here } }; This doesn't answer the most important question -- why does Context.getContext() return null -- but it might give you a workaround. --tim On Wed, Aug 13, 2008 at 4:54 PM, Chris Lee <[EMAIL PROTECTED]>wrote: > Hey guys, I followed

Re: Guice and 1.1m5

xt will > be returned by getContext(), no default context 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 wha

Re: Guice and 1.1m5

Sounds as though the call to Context.getCurrent() is somehow happening in a thread for which Context.setCurrent has not been called. I can reproduce the behavior with 1.1m5, so when I get a chance I'll dig deeper. I'm assuming this is not very urgent, given the Application.getCurrent().getContext()

Re: Guice and 1.1m5

t.zip > > 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

Re: Using the standalone server

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

Re: Using the standalone server

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

Re: Using the standalone server

s doing > something more 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,

Re: Using the standalone server

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 line

Re: Using the standalone server

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

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 f

Re: XmlRepresentation.internalEval

nk it will be good to clean them in the > code to prevent people getting worried. Let me know! > > Best regards, > Jérôme Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > ----

<    1   2   3   4   >