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
). Leaving
them non-final is not correct.
--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
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
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
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
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
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
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
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
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
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.
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
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.
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?
-
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) + '=' +
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
:* [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
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
] [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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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:
On Mon, Nov 3, 2008 at 1:43 PM, Thierry Boileau [EMAIL PROTECTED]
wrote:
NB:
for a complete list of supported predefined variables:
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,
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
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
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
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
!
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
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
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
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,
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.
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
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
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
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:
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
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,
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
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
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) {
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)
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
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
...@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 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
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
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
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
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
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
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
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
~ 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
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
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
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
, 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
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
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 - 100 of 347 matches
Mail list logo
