Base 64 encoding

[webpost]

Hi there,

The client wants base 64 encoded representation(html) from the server for a 
given resource.

how do i accomplish that?

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402360

RE: Re: Re: Netty extension

[Gabriel Ciuloaica]

The issue was in my code, did not played right with input/output streams, and 
is doesn't have anything to do with the way that the Resource is implemented.

Thanks,
Gabi

> Hi Jerome,
> 
> I'm very close to finalize the patch for Netty extension, but I have some 
> test cases that are failing. I'm still investigating the issue. it happens 
> when I try to use a ServerResource instance implemented without using 
> annotations 
> (jax-rs).
> 
> I have updated the existing test cases from org.restlet.test to test the 
> Netty extension in same way like the other server extensions.
> 
> Thanks,
> Gabi

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402266

2.0m5 ClientResource.get() returns null

[Patrick Logan]

The docs for ClientResource.get() indicates a ResourceException will be thrown 
if the status is not a success. Given a ClientResource on a URL for a bad 
domain, e.g. the misspelled "http://www.estlet.org"; results in null rather than 
an exception.

The log includes messages like...

INFO: A recoverable error was detected (1001), attempting again in 1000 ms.

Is this expected, and the docs are misleading? Or should the result actually be 
a ResourceException?

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402253

Re: logging framework for restlet

[Rhett Sutphin]

Hi Jerome,

On Sep 30, 2009, at 5:23 AM, Jerome Louvel wrote:

> Beside the simplicity of requiring a single JAR (important),

This is a reasonable concern -- if you used SLF4J in restlet core,  
you'd go from 1 JAR to (at least) 3 JARs (restlet, slf4j-api, and an  
slf4j implementation).  However, I wonder how many restlet users  
actually only use the core.  Have you ever done a survey?

> the size
> concern (minor indeed), the licensing aspect (with a multi-license  
> scheme
> for Restlet),

SLF4J is MIT licensed: http://slf4j.org/license.html .

> the 'zero dependency rule' is also helpful when we support
> Restlet editions like GWT/GAE or Android where an external  
> dependency might
> not work seamlessly (not sure about SLF4J though).

I haven't tried using SLF4J in any of those environments (though I  
found evidence that it will work on GAE[1]), but the core SLF4J code  
is really, really simple.

[1]: 
http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.html

> If performance through JULI+SLF4J is really bad, maybe you chould  
> look at a
> direct bridge from JULI to the logging framework you selected?

The performance issue that Arjohn brought up is on the JUL side, not  
on the SLF4J side.

> Another option would be for Restlet to provide a simple pluggable  
> logging
> mechanism that would use JULI API for levels, logger, etc. and JULI  
> 'engine'
> as the default implementation. But the implementation could be  
> replaced
> through dynamic detection of SLF4J for example. Would that be a better
> solution?

Dynamic detection sounds a lot like Jakarta commons-logging.  JCL  
introduces all sorts of classloading issues -- JCL is the problem that  
SLF4J was designed to solve.  A restlet-provided dynamic detection  
solution would have to be carefully designed to be OSGi compatible as  
well.

If the concern is efficiency (and meaning no offense to you, Jerome),  
it seems unlikely that a restlet-provided bridge from JULI to SLF4J is  
going to be faster than the one provided by SLF4J itself.

Rhett

> BTW, I've updated the related RFE:
>
> "Facilitate support of alternative log mechanisms"
> http://restlet.tigris.org/issues/show_bug.cgi?id=179
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -Message d'origine-
> De : Arjohn Kampman [mailto:arjohn.kamp...@aduna-software.com]
> Envoyé : vendredi 18 septembre 2009 19:13
> À : discuss@restlet.tigris.org
> Objet : Re: logging framework for restlet
>
> Rhett Sutphin wrote:
>> Hi Arjohn,
>>
>> On Sep 18, 2009, at 10:31 AM, Arjohn Kampman wrote:
>>
>>> I was wondering if you ever considered to use a logging framework  
>>> such
>>> as slf4j instead of using java util logging directly. This can make
>>> integration of restlet in applications that don't use JUL a lot
>>> easier.
>>
>> I'd be in favor of this, too, but the core team is dedicated zero
>> dependencies in the core of the framework.  Here's a discussion from
>> last March:
>>
>> http://markmail.org/search/?q=restlet%20slf4j#query:restlet%20slf4j
>> +page:1+mid:spk4x55pegqktg2y+state:results
>
> Guess this has had some attention before. Thanks for the pointer.
>
> Reading through Jerome's comments:
>
>> There is also a bridge from JUL to sl4j (http://www.x4juli.org/) that
>> you could leverage.
>
> x4juli actually works the other way around: it implements the slf4j  
> APIs
> so you can use it as a logger in the slf4j framework.
>
> There is a jul-to-slf4j bridge available from slf4j.org, but that is
> said to add considerable overhead to the logging:
>
> "Consequently, j.u.l. to SLF4J translation can seriously impact on the
> cost of disabled logging statements (60 fold increase) and a  
> measurable
> impact on enabled log statements (20% overall increase)."
> -- http://slf4j.org/legacy.html
>
>> A main design constraint that we have is zero external dependency for
>> the Restlet API/Engine beside the JRE. It is good for compactness,
>> facility of deployment
>
> Good arguments, I would say.
>
>> and also because we don't want to force our users to use one logging
>> mechanism over another.
>
> Now here's the funny thing: based on the exact(!) same argument, we
> actually decided to switch from jul to slf4j. Getting jul to bridge to
> slf4j seems to be non-trivial task, while the reverse is as simple as
> adding the appropriate jar-file to your classpath.
>
> So the main question now seems to be: is this sufficient reason to add
> a small (30kb) external dependency to restlet?
>
> -- 
> Arjohn
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23965
> 48
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401976

--
http://restl

RE: 2.0snap GWT getEntity().getText() works again

[weltermann17]

Hi Jerome,

getStream() is correctly only called once in the Restlet GWT
stream-handling. It was an error in my debugging code. I called
response.getEntity().getText() more than once. As the underlying
representation on GWT always is an InputRepresentation the problem is more
inside the getText method:

public String getText() throws IOException {
return ByteUtils.toString(getStream(), getCharacterSet());
}

The docs don't warn that this should be called only once and not at all if a
getStream() is called. It's probably better to make this method more robust
by caching the text in private member.

response.getEntityAsJson().getText() can safely be called more than once (if
it makes sense).

I think the modification in M5 (check for Editon GWT in
InputRepresentation.getStream()) can be reverted.

Regards,
Guido.
-- 
View this message in context: 
http://n2.nabble.com/2-0snap-GWT-getEntity-getText-works-again-tp3711042p3742868.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402094

RE: 2.0snap GWT getEntity().getText() works again

[weltermann17]

Hi Jerome,

I will have a look at the double calling of getStream(). 

After browsing for just a few minutes I withdraw my question: Content-Length
with encoding gzip seems to be a source for numerous disputes and
incompatibilities. Not stating the length header is probably the more robust
and therefore better approach. With fine-tuning of the Encoder class
(setMinimumSize()) it's already possible to define a limit to avoid gzipping
of small representations on the server side.

Digging deeper into your GWT implementation I think that you were facing the
limitations of the GWT RequestBuilder/Response classes. All Response offers
is a "String getText()" even though the representation might be a really
huge gzipped stream. Adding a "Content-Length:
GWT.Response.getText().length()" to the http headers will probably have no
big impact without a lot of refactoring. 

Regards,
Guido.
-- 
View this message in context: 
http://n2.nabble.com/2-0snap-GWT-getEntity-getText-works-again-tp3711042p3742385.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402048

RE: 2.0m4/snap GWT cannot be used at all

[weltermann17]

Hi Jerome,

yes, it's still there: eg.
Window.alert(myValidReference.getTargetRef().toString()) will show the
correct value in compiled mode and throw an uncaught exception in hosted
mode on the console of the GWT hosting application due to IllegalAccessError
on StringBuilder.append(StringBuilder).

Maybe this should be reported to the GWT developers because it's very hard
to track at compile time, esp. for java.lang.* classes. What I really don't
understand is how the GWT compiler manages to generate the correct code from
this emul class.

Of course a quick fix would be to not use any unimplemented methods in GWT,
but this would contradict your very understandable goal to use the same code
base for all editions.

Regards,
Guido.
-- 
View this message in context: 
http://n2.nabble.com/2-0m4-snap-GWT-cannot-be-used-at-all-tp3698316p3742056.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402013

RE: Re: Re: Netty extension

[Gabriel Ciuloaica]

Hi Jerome,

I'm very close to finalize the patch for Netty extension, but I have some test 
cases that are failing. I'm still investigating the issue. it happens when I 
try to use a ServerResource instance implemented without using annotations 
(jax-rs).

I have updated the existing test cases from org.restlet.test to test the Netty 
extension in same way like the other server extensions.

Thanks,
Gabi

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402011

RE: 2.0m4/snap GWT cannot be used at all

[Jerome Louvel]

Hi Guido,

As the entity can now be retrieved correctly (thanks to your help!), I'm
wondering if we still have this issue with Reference#normalize() and
StringBuilder emulation?

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com



-Message d'origine-
De : weltermann17 [mailto:guido.schmidt-...@man.eu] 
Envoyé : mercredi 23 septembre 2009 10:43
À : discuss@restlet.tigris.org
Objet : 2.0m4/snap GWT cannot be used at all

Hi,

several posts have raised the issue that the current GWT edition cannot be
used anymore.

Calling a Client.get works only in hosted but not in compiled mode.

Using Reference.getTargetRef fails in hosted mode with a
"IllegalAccessError" exception due to a call to
StringBuilder.append(StringBuilder) in Reference.normalize. This method is
not implemented in the GWT enum class. 

Maybe the GWT compilation process silently removes code that cannot be
emulated correctly - I don't know. 

Has anybody succeeded in using the current GWT edition and saw the Uniform
callback being actually called in a non-local/non-hosted environment?

As the previous posts are quite old and idle I wonder if this can be fixed
or if it is recommended to create own wrapper classes using
GWT.RequestBuilder to at least get the data from the RESTlet server
resources. This would be a pity regarding the power and elegance of the
RESTlet framework.

Thanks,
Guido.
-- 
View this message in context:
http://n2.nabble.com/2-0m4-snap-GWT-cannot-be-used-at-all-tp3698316p3698316.
html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23987
68

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402002

RE: problem returning a response status

[Jerome Louvel]

Hi Patrizio,

 

We try to reply to all messages in this list (see archives). We just can 
guarantee the order and the delay…

 

If you need timely assistance, you can consider our professional technical 
support offer:

http://www.noelios.com/products/support

 

I know that the Servlet API is tricky about this point. I would need to debug 
this to be sure it is a bug on our side. Could you send us a small application 
reproducing the issue?

 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com

 

 

 

De : Patrizio Munzi [mailto:patrizio.mu...@eris4.com] 
Envoyé : mardi 29 septembre 2009 10:32
À : discuss@restlet.tigris.org
Objet : Re: problem returning a response status

 

May I have a feedback at least...??

Please.

Patrizio Munzi wrote: 

Isn't anybody interested in this??
Restlet developers...??

I think it should be solved..

Thanks

Patrizio Munzi wrote: 

Hi everybody,

I think there's a bug or at least something strange in ResourceException 
management.
The getDescription method works only if I run my application in a stand-alone 
server.
It instead doesn't work if I run in a servlet container (tomcat 5.5).

I'm throwing the following exception server-side:
--
} catch(Throwable e) {
throw new ResourceException(Status.SERVER_ERROR_INTERNAL, 
e.getMessage, e);
   }
--

And here's my client code:
--
try {
Form form = new Form();  
form.add("userId", userId);  
Representation userRepresentation = form.getWebRepresentation();

Request createUserRequest = new Request(Method.POST, createUrl);

createUserRequest.setEntity(userRepresentation);
Response response = client.handle(createUserRequest);
resultStatus = response.getStatus();
} catch (Throwable t) {
System.err.println("Exception in creating User: " + userId + ". 
Exception: " + t);
}
if (resultStatus.isSuccess()) {  
System.out.println("Created User: " + userId + ". Status: " + 
resultStatus.getName() + " - Description: " + resultStatus.getDescription());
}
else {
System.err.println("Error in creating User: " + userId + ". Status: 
" + resultStatus.getName() + " - Description: " + 
resultStatus.getDescription());
}
--

II the application runs in a servlet container I get the following message 
client side:

Error in creating User: TestUser. Status: Internal Server Error - Description: 
OK

instead in a stand alone server I get the right description:

Error in creating User: TestUser. Status: Internal Server Error - Description: 
Test Exception

Has anyone got any idea if it's a bug or I'm doing something wrong

Thanks

Jerome Louvel wrote: 

Hi all,
 
Regarding the propagation of exceptions on the client-side, I've got some plans 
there:
 
"Add exception conversion to ConverterService"
http://restlet.tigris.org/issues/show_bug.cgi?id=878
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
 
 
-Message d'origine-
De : Thierry Boileau [mailto:thierry.boil...@noelios.com] 
Envoyé : vendredi 7 août 2009 18:02
À : discuss@restlet.tigris.org
Objet : Re: problem returning a response status
 
Hello Patrizio  and Laurent,
 
 
you're right Laurent. I notice also there is a lack of documentation 
about this that needs to be addressed.
 
best regards,
Thierry Boileau
 
  

Hello,
Patrizio Munzi a écrit :
  


I'm trying to make work the following simple exception handling.
I just want to return the status specified.
The problem is that client side I cannot retrieve nothing, neither the 
exception or the exception message.
 
I'm surely doing it wrongly, but I haven't find any written explanation on how 
managing exception.
 
Could someone give me some hints to the right way???

  

I think you can do the following in your catch block :
throw new ResourceException(Status.SERVER_ERROR_INTERNAL, e);
If it is not enough, try to extend StatusService class. More info in 
this thread 
http://restlet.markmail.org/message/ptesti33kkk5bksv?q=StatusService
Hope it help.
Regards,
Laurent.
 
  


Thanks
 
---
@Post
public void createUser(Representation entity) {
try {
// Parse the given representation and retrieve pairs of  
// "name=value" tokens.  
Form form = new Form(entity);  
String userId=form.getFirstValue("userId");  
 
myApplication.createUser(userId);
 
setStatus(Status.SUCCESS_CREATED, "Created User: " + userId);  
} catch(Throwable e) {
 
e.printStackTrace();
setStatus(Status.SERVER_E

RE: 2.0snap GWT getEntity().getText() works again

[Jerome Louvel]

Hi Guido,

Thanks for your reply. If you could check the cause of this double call to
getStream() in GWT that would be very nice!

Regarding the Content-Length header, my understanding of the HTTP spec it is
the actual size, after content encoding. 

I'm not sure if how much gain we would have but I entered a new RFE that
would provide a different solution to this issue:

"Add buffer option to ConnectorService"
http://restlet.tigris.org/issues/show_bug.cgi?id=907

Let me know what you think.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com




-Message d'origine-
De : weltermann17 [mailto:guido.schmidt-...@man.eu] 
Envoyé : mardi 29 septembre 2009 18:32
À : discuss@restlet.tigris.org
Objet : RE: 2.0snap GWT getEntity().getText() works again

Hi Jerome,

I could see that in M5 a check for Editon equals GWT was added and already
thought that this would be a temporary fix only as it breaks the contract
for InputRepresentation.getStream(). 

Reading the docs for getStream and isTransient makes it quite clear why a
call to getStream().available() to check is something was received breaks
the whole stream-handling. If you want I can try to find out where it's
called once too often in the current trunk in order to switch back to the
indented behaviour on GWT also.

With some testing I found out that the "missing" header Content-Length is
due to the usage of an Encoder filtered before a ServerResource. This
setting does exactly what I want (I create really large JSON representations
with sometimes 5-10mb that benefit dramatically from using gzip encoding).

>From what I know stating the actual Content-Length for a Content-Encoding:
gzip is allowed and can be a great help on the client side. Do you think it
would make sense to enhance the Encoder to add this header for a
fixed-length Representation? I think that on the GWT side this would avoid a
lot of stream handling and generate the corresponding fixed-length
Representation right away? 

Best regards,
Guido.


-- 
View this message in context:
http://n2.nabble.com/2-0snap-GWT-getEntity-getText-works-again-tp3711042p373
7351.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24017
04

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401996

RE: 2.0snap GWT getEntity().getText() works again

[Jerome Louvel]

Hi Rickard,

The issue of this current thread is really different. It was due to bugs in
our GWT/Java emulation code.

The issue on the server side with Tomcat was due to the
Representation#finalize() method that was calling Representation#release(),
trying to close the stream and sometimes flushing Tomcat buffers already
reused for subsequent requests. 

In Restlet 2.0 M5 and beyond the is no more finalize() method on
Representation. After benchmarking, I was able to confirm that this fixed
the issue. If there is still some issue, it must have a different cause.

Are you certain that the snapshot you are using is very recent? From the
Maven repo is only updated twice a month... Testing with M5 tomorrow would
definitely answer that.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com



-Message d'origine-
De : Rickard Öberg [mailto:rickardob...@gmail.com] 
Envoyé : mercredi 30 septembre 2009 03:39
À : discuss@restlet.tigris.org
Objet : Re: 2.0snap GWT getEntity().getText() works again

weltermann17 wrote:
> I could see that in M5 a check for Editon equals GWT was added and already
> thought that this would be a temporary fix only as it breaks the contract
> for InputRepresentation.getStream(). 
> 
> Reading the docs for getStream and isTransient makes it quite clear why a
> call to getStream().available() to check is something was received breaks
> the whole stream-handling. If you want I can try to find out where it's
> called once too often in the current trunk in order to switch back to the
> indented behaviour on GWT also.

Sorry for not fully understanding this issue, but could this also be 
related to my problems with "getRequest().getEntityAsText() returns 
null" on the serverside? I posted about this issue some time ago, and 
Jerome said it was fixed in Restlet-2.0-SNAPSHOT, which we are now using.

But yesterday I saw it again in the logs! We never get this issue on our 
local dev computers, but get it all the time on our EC2 test instance, 
so if it is related to available() returning false due to slow 
connection, that sounds reasonable.

Is that a possibility? If not, we are going to try Jetty instead of 
Tomcat as the container and see if that helps.

/Rickard

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24018
41

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401987

RE: logging framework for restlet

[Jerome Louvel]

Hi Arjohn,

Beside the simplicity of requiring a single JAR (important), the size
concern (minor indeed), the licensing aspect (with a multi-license scheme
for Restlet), the 'zero dependency rule' is also helpful when we support
Restlet editions like GWT/GAE or Android where an external dependency might
not work seamlessly (not sure about SLF4J though).

If performance through JULI+SLF4J is really bad, maybe you chould look at a
direct bridge from JULI to the logging framework you selected?

Another option would be for Restlet to provide a simple pluggable logging
mechanism that would use JULI API for levels, logger, etc. and JULI 'engine'
as the default implementation. But the implementation could be replaced
through dynamic detection of SLF4J for example. Would that be a better
solution?

BTW, I've updated the related RFE:

"Facilitate support of alternative log mechanisms"
http://restlet.tigris.org/issues/show_bug.cgi?id=179

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : Arjohn Kampman [mailto:arjohn.kamp...@aduna-software.com] 
Envoyé : vendredi 18 septembre 2009 19:13
À : discuss@restlet.tigris.org
Objet : Re: logging framework for restlet

Rhett Sutphin wrote:
> Hi Arjohn,
> 
> On Sep 18, 2009, at 10:31 AM, Arjohn Kampman wrote:
> 
>> I was wondering if you ever considered to use a logging framework such
>> as slf4j instead of using java util logging directly. This can make
>> integration of restlet in applications that don't use JUL a lot  
>> easier.
> 
> I'd be in favor of this, too, but the core team is dedicated zero  
> dependencies in the core of the framework.  Here's a discussion from  
> last March:
> 
> http://markmail.org/search/?q=restlet%20slf4j#query:restlet%20slf4j 
> +page:1+mid:spk4x55pegqktg2y+state:results

Guess this has had some attention before. Thanks for the pointer.

Reading through Jerome's comments:

 > There is also a bridge from JUL to sl4j (http://www.x4juli.org/) that
 > you could leverage.

x4juli actually works the other way around: it implements the slf4j APIs
so you can use it as a logger in the slf4j framework.

There is a jul-to-slf4j bridge available from slf4j.org, but that is
said to add considerable overhead to the logging:

"Consequently, j.u.l. to SLF4J translation can seriously impact on the
cost of disabled logging statements (60 fold increase) and a measurable
impact on enabled log statements (20% overall increase)."
-- http://slf4j.org/legacy.html

 > A main design constraint that we have is zero external dependency for
 > the Restlet API/Engine beside the JRE. It is good for compactness,
 > facility of deployment

Good arguments, I would say.

 > and also because we don't want to force our users to use one logging
 > mechanism over another.

Now here's the funny thing: based on the exact(!) same argument, we
actually decided to switch from jul to slf4j. Getting jul to bridge to
slf4j seems to be non-trivial task, while the reverse is as simple as
adding the appropriate jar-file to your classpath.

So the main question now seems to be: is this sufficient reason to add
a small (30kb) external dependency to restlet?

-- 
Arjohn

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23965
48

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401976

RE: Turn off access logging for a specific resource?

[Jerome Louvel]

Hi Aaron,

This is possible by leveraging the engine filter used by the LogService:
http://www.restlet.org/documentation/snapshot/jse/engine/org/restlet/engine/
log/LogFilter.html

This filter should be put right before your special resource using the
routing API. You should then turn off the component's log service to prevent
double processing. 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com



-Message d'origine-
De : webp...@tigris.org [mailto:webp...@tigris.org] 
Envoyé : mercredi 16 septembre 2009 00:04
À : discuss@restlet.tigris.org
Objet : Turn off access logging for a specific resource?

Hi Restlet Community,

I'd like to surgically squelch access logging for just one of my Resources.

I've figured out how to do this via external logging configuration, but it's
a little ugly. It filters by parsing the already-formatted access log
message and matching on the path. I'm able to apply the filter only to the
"org.restlet.Component.LogService" logger, but I'd still like a cleaner
solution that targets just the specific Resource.

Does the Restlet framework provide a clean programmatic way to do this?


Many thanks for any hints!
Aaron

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23952
69

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401966

RE: Visibility problem with com.noelios.restlet.ext.oauth.OAuthProvider

[Jerome Louvel]

Hi ZDC,

I can't change the API of Restlet 1.1. However I've changed SVN trunk (2.0)
to have those methods public.

As a temporary workaround, you could declare your providers in the
com.noelios.restlet.ext.oauth' package.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com



-Message d'origine-
De : ZDC [mailto:zhudach...@yahoo.com] 
Envoyé : jeudi 3 septembre 2009 15:48
À : discuss@restlet.tigris.org
Objet : Visibility problem with com.noelios.restlet.ext.oauth.OAuthProvider

Hi,

When I tried to implement my own OAuth Provider by extending the abstract
class "OAuthProvider" under the package
"com.noelios.restlet.ext.oauth.OAuthProvider", I could not do that becuase
the methods are not visible outside the package (e.g. methods are not
public).

I can easily change it locally but I just want to ask what's the approciate
way to extend the work done by Sir Adam Rosien from Noelios Technologies.

BRs,

ZDC

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23906
67

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401934

Re: url encoded string can not be used in the path

[Jerome Louvel]

FYI, see reply in other thread:
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2389063

Note: Please don't post multiple times. Just be patient, messages from 
new users are moderated.



webp...@tigris.org wrote :
> I have this string as authentication token :
> 
> FtDF91VSX/7AN6C39k51​ZV510SW/ot6SIGstq8XG​ 
> CcHfOfHbZOZLUD4u+GUN​K0bBawVZ4GR5TgV7PtRb​F+nm9abYJN6AWycdj9J6​ 
> CLyU4D7Zou36KEjkel+0​LtlGGhFPVrCvpBuqPy8V​8o5IZ9tDys0Py6sXXAtE​ 
> VbXBYeRYzOvIBzOZkIvi​IyceVCU+lYv/h9k7Fhlb​1JGtKUCj3ZDg/vJ1Co7d​ 
> OC1Ho3/e0Fup7k9qgTuC​vZRSHcpizaEFPNLp
> 
> after I encode it, I still can not embed it in a url e.g. 
> http://aabc.com/{token}/books/{bookid}, please let me know what is the 
> problem ?
> 
> Thanks
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2391069
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401933

Re: url encoded string in the path

[Jerome Louvel]

FYI, see reply in this other thread:
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2389063


webp...@tigris.org wrote :
> I have a string like this
> FtDF91VSX/7AN6C39k51ZV510SW/ot6SIGstq8XGCcHfOfHbZOZLUD4u+GUNK0bBawVZ4GR5TgV7PtRbF+nm9abYJN6AWycdj9J6CLyU4D7Zou36KEjkel+0LtlGGhFPVrCvpBuqPy8V8o5IZ9tDys0Py6sXXAtEVbXBYeRYzOvIBzOZkIviIyceVCU+lYv/h9k7Fhlb1JGtKUCj3ZDg/vJ1Co7dOC1Ho3/e0Fup7k9qgTuCvZRSHcpizaEFPNLp
> in my url, after encoded it, it will be 
> FtDF91VSX%2F7AN6C39k51ZV510SW%2Fot6SIGstq8XGCcHfOfHbZOZLUD4u%2BGUNK0bBawVZ4GR5TgV7PtRbF%2Bnm9abYJN6AWycdj9J6CLyU4D7Zou36KEjkel%2B0LtlGGhFPVrCvpBuqPy8V8o5IZ9tDys0Py6sXXAtEVbXBYeRYzOvIBzOZkIviIyceVCU%2BlYv%2Fh9k7Fhlb1JGtKUCj3ZDg%2FvJ1Co7dOC1Ho3%2Fe0Fup7k9qgTuCvZRSHcpizaEFPNLp
> if I use this encoded string as token in the path,e e.g. 
> /{token}/bookstore/{bookid} directly, it won't work, I have to add it as 
> query using form like 
> /token?token/bookstore/{bookid} to make it work. any suggestion why the 
> encoded string won't work ?
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2389050
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401925

RE: missing something stupid with static files

[Jerome Louvel]

Hi Troy,

Were you able to solve this? Maybe you need a trailing slash when you attach
the directory:

router.attach("/images/", d);

There is a working sample in the tutorial in case you need it:
http://www.restlet.org/documentation/2.0/tutorial#part06

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : troy [mailto:troycau...@gmail.com] 
Envoyé : lundi 31 août 2009 17:00
À : discuss@restlet.tigris.org
Objet : missing something stupid with static files

I have some Resources working, but I can't seem to get a static
Directory working.  Does this look right?

public class ControlApp extends Application
{
@Override
public synchronized Restlet createRoot()
{
Router router = new Router(getContext());

// resource routes work
router.attach("/user/{login}/foo", FooResource.class);
router.attach("/user/{login}/foo/{fooID}", FooResource.class);

// static files do not work
String ROOT_URI = "file:///tmp/";
Directory d = new Directory(getContext(), ROOT_URI);
d.setListingAllowed(true);
d.setDeeplyAccessible(true);
router.attach("/images", d);

return router;
}
}


Yes, I added the FILE protocol to the component.

  component.getServers().add(Protocol.HTTP, 8182);
  component.getClients().add(Protocol.FILE);


Thanks,
tlc

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23889
41

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401923

RE: url encoded string in the route

[Jerome Louvel]

Hi Hank,

I've just wrote a unit test to cover your case (see attached, especially
method testEncodedCharacters()). But it seems to work just fine...

Could you provide some sample code to reproduce?

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com




-Message d'origine-
De : hank z [mailto:hzhu...@directv.com] 
Envoyé : lundi 31 août 2009 19:25
À : discuss@restlet.tigris.org
Objet : url encoded string in the route

I have a string like this
FtDF91VSX/7AN6C39k51ZV510SW/ot6SIGstq8XGCcHfOfHbZOZLUD4u+GUNK0bBawVZ4GR5TgV7
PtRbF+nm9abYJN6AWycdj9J6CLyU4D7Zou36KEjkel+0LtlGGhFPVrCvpBuqPy8V8o5IZ9tDys0P
y6sXXAtEVbXBYeRYzOvIBzOZkIviIyceVCU+lYv/h9k7Fhlb1JGtKUCj3ZDg/vJ1Co7dOC1Ho3/e
0Fup7k9qgTuCvZRSHcpizaEFPNLp
in my url, after encoded it, it will be 
FtDF91VSX%2F7AN6C39k51ZV510SW%2Fot6SIGstq8XGCcHfOfHbZOZLUD4u%2BGUNK0bBawVZ4G
R5TgV7PtRbF%2Bnm9abYJN6AWycdj9J6CLyU4D7Zou36KEjkel%2B0LtlGGhFPVrCvpBuqPy8V8o
5IZ9tDys0Py6sXXAtEVbXBYeRYzOvIBzOZkIviIyceVCU%2BlYv%2Fh9k7Fhlb1JGtKUCj3ZDg%2
FvJ1Co7dOC1Ho3%2Fe0Fup7k9qgTuCvZRSHcpizaEFPNLp
if I use this encoded string as token in the path,e e.g.
/{token}/bookstore/{bookid} directly, it won't work, I have to add it as
query using form like 
/token?token/bookstore/{bookid} to make it work. any suggestion why the
encoded string won't work ? I also find that if I move the token to some
other location, it works, but there has to be at least one query stirng in
front in the path, such as /token1?{token1}/{token}/bookstore/{bookid}, int
this case, I can use url encoded token in second segment directly.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23890
63

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401922

TemplateTestCase.java
Description: Binary data

RE: PROBLEM WITH org.restlet.representation.InputRepresentation IN 1.2-M2

[Jerome Louvel]

Hi Rickard,

The public Maven repository is updated twice a month (1st and 15th). You
should get it tomorrow: http://www.restlet.org/downloads/maven

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : Rickard Öberg [mailto:rickardob...@gmail.com] 
Envoyé : mercredi 30 septembre 2009 07:02
À : discuss@restlet.tigris.org
Objet : Re: PROBLEM WITH org.restlet.representation.InputRepresentation IN
1.2-M2

On 2009-09-24 22.43, Jerome Louvel wrote:
> Hi Denys,
>
> After further investigation, the fix related to annotated methods wasn't
> enough. There was indeed an issue as you initially reported with the
> Representation#finalize() method.
>
> I was finally able to reproduce it consistently, forcing the GC to run
> and to fix it by removing the finalize() method.
>
> It means that developers won't be able to rely on the GC to ultimately
> release pending connection which isn't a safe bet anyway.
>
> The fix is in SVN trunk and will be part of Restlet 2.0 M5.

I just saw that Maven Restlet-2.0-SNAPSHOT is not updated every day, so 
we are not guaranteed to get this fix ASAP. Is there any way you could 
force a new snapshot to be created? We are in desperate need of this fix :-(

/Rickard

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24018
67

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401919

RE: Issue with JaxbRepresentation in 2.0 M5 (Was: 2.0 M5 is broken)

[Jerome Louvel]

Hi there,

The JaxbConverter was improved right after 2.0 M5 by Sanjay Acharya. I think 
the current getObjectClasses() method in SVN trunk does exactly what you 
propose.

Contributions of improvements are welcome of course. Note that two test cases 
were also contributed by Sanjay.

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : infinity [mailto:infinity2hea...@gmail.com] 
Envoyé : mercredi 30 septembre 2009 00:14
À : discuss@restlet.tigris.org
Objet : RE: Issue with JaxbRepresentation in 2.0 M5 (Was: 2.0 M5 is broken)

JaxBConverter was added in 2.0M5 and the implementation is broken. I wrote a
custom JaxBConverter and registered; seems to be working. 

There are a few things:
1) null checks to return an EmptyRepresentation() needs to be implemented
2)  getObjectClasses has been overridden incorrectly. 

public List> getObjectClasses(Variant source) {   
List> result = null;
return result;
}

I changed to:

public List> getObjectClasses(Variant source) {
List> result = null;

if (VARIANT_APPLICATION_ALL_XML.isCompatible(source)
|| VARIANT_APPLICATION_XML.isCompatible(source)
|| VARIANT_TEXT_XML.isCompatible(source)) {
 result = addObjectClass(result, JaxbRepresentation.class);
 }

return result;
}

I can provide a patch in a day or two once tested thoroughly.




jlouvel wrote:
> 
> Hi anonymous,
> 
> I've changed the title because it wasn't very informative...
> 
> I confirmed that nothing changed in the JaxbRepresentation since 2.0 M4.
> So,
> it must be related to something else, like your resource class.
> 
> Could you send over some working code reproducing your issue?
> 
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
> 
> 
> -Message d'origine-
> De : infinity [mailto:infinity2hea...@gmail.com] 
> Envoyé : lundi 28 septembre 2009 21:09
> À : discuss@restlet.tigris.org
> Objet : 2.0 M5 is broken
> 
> I've spend two hours debugging my application just to realize that "just
> by
> replacing 2.0 M4" jars, the applications works fine. 
> 
> Somewhere in my app code, I return a http status, followed by a Xml
> object,
> however in 2.0 M5 the xml object is never returned (the http error status
> is
> returned or an empty xml is returned)
> 
> return new JaxbRepresentation(MediaType.TEXT_XML, error);
> 
> I looked at the changelog of M5 and doesn't appear to me that anything has
> changed wr JaxbRepresentation
> 
> WHAT has changed?
> -- 
> View this message in context:
> http://n2.nabble.com/2-0-M5-is-broken-tp3731286p3731286.html
> Sent from the Restlet Discuss mailing list archive at Nabble.com.
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24013
> 64
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401487
> 
> 

-- 
View this message in context: 
http://n2.nabble.com/2-0-M5-is-broken-tp3731286p3739302.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401802

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401917