Empty @Get() annotation overwrites already retrieved representation mimetype

[Joe Nellis]

Greetings,

The following code at ServerResource#doHandle(AnnotationInfo ,Variant )
seems backwards perhaps. (2.0m3snapshot)

if (resultObject != null) {
// TODO This is a shortcut in case the resource does not
// precise the media-type of the representation. This should
be
// enhanced, maybe with a media type "unknown" for the
// negotiated variant.
if (resultObject instanceof Representation) {
result = (Representation) resultObject;
if (variant.getCharacterSet() != null) {
result.setCharacterSet(variant.getCharacterSet());
} else if (variant.getMediaType() != null) {
result.setMediaType(variant.getMediaType());
} else if ((variant.getLanguages() != null)
&& !variant.getLanguages().isEmpty()) {
result.setLanguages(variant.getLanguages());
} else if ((variant.getEncodings() != null)
&& !variant.getEncodings().isEmpty()) {
result.setEncodings(variant.getEncodings());
}
} else {
result = cs.toRepresentation(resultObject, variant,
this);
}
}

So what is the purpose of this code and were the Else-If's the intended
logic?  The "variant" variable is ultimately from the
ClientInfo.getPreferredVariant and such if we are testing for
Representations that don't have variant "stuff" set then testing the client
preferred variant being set for these things doesn't seem the right
direction to take. The else if's make these checks short circuit if one is
true, why is that?

Currently if you use a @Get() annotation with no extention value or "" this
bit of code will get your representation's media type overwritten with some
other media type. When I use riap via a getClientDispatcher it overwrites it
with 'application/json' but normally it does it with 'application/xml'.

Sincerely,
Joe Nellis

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

RE: Re: HTML Email

[Jerome Louvel]

Hi guys,

 

I’ve entered a related RFE and attached Rémi’s patch to it:

 

“Support multipart mails in JavaMail extension”

http://restlet.tigris.org/issues/show_bug.cgi?id=854

 

We’ll get to this for 2.0 M5.

 

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

 

 

 

De : remidewi...@gmail.com [mailto:remidewi...@gmail.com] De la part de Rémi 
Dewitte
Envoyé : mercredi 15 juillet 2009 10:16
À : discuss@restlet.tigris.org
Objet : Re: Re: HTML Email

 

Hello,

Using this, you no longer use  but  tags, the patch is pretty 
understandable. It would be nice you take it and submit a proper patch for the 
current SVN trunk !

Hope it helps,
Rémi

On Fri, Jul 10, 2009 at 22:32,  wrote:

I'd love to get that multi-part patch.   Can you post the code?

thanks

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

 &dsMessageId=2370212

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

Re: Guidance on Atom/APP in Restlet

[Rob Heittman]

All valid points.  There must be cooperation between a client and server at
some level!

I have two problems with RPC style implementations on the Web:

1) The RPC paradigm hides the advanced properties of the Web and makes them
really difficult to leverage

2) The RPC protocol and serialization behavior is totally opaque to any
client or server not using a compatible RPC library, of which (as in GWT)
there is usually only one, in one language.

Jerome's proposed use of the GWT RPC serialization works around both of
these objections.  Objection #1 goes away because the serialized
representations are exposed using Restlet.  Objection #2 goes away for two
reasons:

a) (weak) The GWT RPC serialization is not really very opaque (compared to,
say RMI tunnelled over HTTP).  It's JSON and, while terse, not beyond
comprehension.  I have actually written stuff to do GWT RPC server interop
with non-GWT clients, and it's possible, if yucky.

b) (strong) Restlet makes it trivial to expose alternate variants (e.g. XML,
HTML) for other clients, which you just can't do with RPC alone.

So I'm signed up for the serialization train.

- R

On Sat, Jul 25, 2009 at 5:44 AM, Jerome Louvel wrote:

> But wait! XML and JSON do introduce coupling as you need to know their
> structure in advance most of the time! If you want an even less coupling,
> then looking towards RDF is a good idea but still you will need to
> understand some ontologies...
>

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

Re: Help! -- Error handler isn't working

[Schley Andrew Kutz]

I changed the package name last night :(

http://vangaea.svn.sourceforge.net/viewvc/vangaea/trunk/src/main/java/com/hyper9/vangaea/server/rest/BaseResource.java?view=markup

Here is the updated link. Thanks!

--  
-a

"Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former." -- Einstein

On Jul 25, 2009, at 6:01 AM, Jerome Louvel wrote:

> Hi Schley,
>
> I could open your link (404). By default, the exception doesn't  
> appear in the browser to not expose too much internal details. You  
> can customize the StatusService if needed.
>
> I agree it would be nice to have such an option available so I've  
> updated this RFE:
>
> "Return clear status description when exception caught"
> http://restlet.tigris.org/issues/show_bug.cgi?id=852
>
> 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
> Envoyé : jeudi 23 juillet 2009 01:07
> À : discuss@restlet.tigris.org
> Objet : Re: Help! -- Error handler isn't working
>
> Jerome,
>
> Sorry about that (updated). Here is the ViewVC link to the file  - 
> http://vangaea.svn.sourceforge.net/viewvc/vangaea/trunk/src/main/java/com/h9labs/vangaea/server/rest/BaseResource.java?view=markup
> .
>
> I've updated the code to take advantage of M4's doCatch handler.
> However, when I throw a ResourceException in the doInit() method, or
> any method, the ResourceException is not being displayed in the
> browser, and I was under the impression that it should.
>
> Thanks!
>
> -- 
> -a
>
> "Only two things are infinite, the universe and human stupidity, and
> I'm not sure about the former." -- Einstein
>
> On Jul 21, 2009, at 2:53 AM, Jerome Louvel wrote:
>
>> Hi Schley,
>>
>> Could you send us your project (or a snippet reproducing the issue)
>> and
>> Restlet environment details (version, OS, etc.)? It should
>> definitely work.
>>
>> BTW, I suggest that you use more meaningful email title when you  
>> post,
>> easier for tracking and searching in the archives.
>>
>> 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
>> Envoyé : mardi 14 juillet 2009 21:52
>> À : discuss@restlet.tigris.org
>> Objet : Help!
>>
>> The StringRepresentation returned by 'public Representation handle()'
>> is no longer appearing in the browser when I access my server.
>>
>> Here is an example:
>>
>> @Override
>>public Representation handle()
>>{
>>if (true) return new StringRepresentation("Hello, world.");
>>...
>>
>> That should ALWAYS trump any other logic and show Hell, world. in the
>> browser. Was a bug introduced to the Maven snapshot? Or do you  
>> think I
>> could have farked myself somehow.
>>
>> -- 
>> -a
>>
>> "Ideally, a code library must be immediately usable by naive
>> developers, easily customized by more sophisticated developers, and
>> readily extensible by experts." -- L. Stein
>>
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23713
>> 20
>>
>> --
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372837
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2374613
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2375508

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

RE: Parameters of media-type

[Jerome Louvel]

Hi Evgeny,

Thanks for reporting this issue. It should be fixed in SVN trunk. I have
also trimmed spaces around parameter names when accessing them via
MediaType#getParameters().

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 : news [mailto:n...@ger.gmane.org] De la part de Evgeny Shepelyuk
Envoyé : jeudi 23 juillet 2009 10:01
À : discuss@restlet.tigris.org
Objet : Parameters of media-type

Hello,
I'm using Restlet 2.0m3
What i need is to receive following string of content-type in HTTP  
response.

Content-type: multipart/x-mixed-replace; boundary="My boundary"

When i'm using code like this

MediaType.valueOf(\"multipart/x-mixed-replace; boundary=\"My boundary\"")

i receive following in response

Content-Type: multipart/x-mixed-replace; boundary="My boundary";   
boundary="My boundary"

Also i cant add parameter programmaticaly since parameters are  
unmodifiable in MediaType class.
How can i solve my problem ?


-- 
Regards,
Evgeny Shepelyuk

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

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

RE: Premature EOF / Broken Pipe

[Jerome Louvel]

Hi Timothy,

 

Let us know how it goes when using Jetty for example as the HTTP server 
connector. If you were using Tomcat, you might want to check this issue which 
might be related:

 

“getText() returns empty text with Tomcat”

http://restlet.tigris.org/issues/show_bug.cgi?id=843

 

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

 

 

 

De : Timothy Aanerud [mailto:taane...@aticonsulting.com] 
Envoyé : mercredi 15 juillet 2009 18:06
À : discuss@restlet.tigris.org
Objet : Re: Premature EOF / Broken Pipe

 

My real application is still the only place I can reproduce the problem.  While 
watching the client and server both run within Eclipse I can add one more 
observation about the order of events when the exceptions occur.

My client is POSTing a message to a resource.  When the problem occurs the 
client's call to  

{ new Client(Protocol.HTTP).post(url, representation) }

does not return for ~30 seconds.  The my client application does not throw an 
exception until after the server has thrown it's exceptions.

My server resource is receiving an acceptRepresentation call but is throwing an 
exception because the Representation entity it receives has a problem of some 
sort.  It's attempting to create a new Form(entity).  When it throws it's first 
exception.  The form is only partially parsed because of a java.io.IOException: 
Broken pipe.The resource then attempts to use the incomplete form object, 
throws a few more exceptions that are caught.

Watching it happen I'd say that the server exceptions have all occured before 
the client throws it's Premature EOF exception.

Jerome's initial suggestion to my problem was to try different http connectors. 
  I initially didn't realize how easy that was to do until I saw an old  
posting from Thierry refering to these links.
http://www.restlet.org/documentation/1.1/faq#04 & 
http://www.restlet.org/documentation/1.1/faq#05
Just change the class path.  I didn't realize it was that easy. :-)

My first change was to switch my client to the Apache httpclient.  I'm going to 
run my client over night and see if I have any errrors.
--
Timothy Aanerud



On Sun, Jul 5, 2009 at 6:27 AM, Jerome Louvel  wrote:

Hi Timothy,

 

Thanks for updating us. Let’s keep an eye on it and if you find a way to 
reproduce it, please let us know!

 

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

 

 

 

De : Timothy Aanerud [mailto:taane...@aticonsulting.com] 
Envoyé : mercredi 1 juillet 2009 20:53
À : discuss@restlet.tigris.org


Objet : Re: Premature EOF / Broken Pipe

 

I tried adding a second resource to my sample application.  But it doesn't fail.

In my actual application I have a scheduled background thread doing a POST 
transaction, immediately followed by a GET transaction. The Premature EOF 
exception has always occurred in the POST transaction.  Since order does not 
matter between these two message exchanges, I switched them around.  After 
doing this and trying several different scheduled time intervals for the 
background thread, I have yet to see it fail using the 
org.restlet.Client.Client using org.restlet.data.Protocol.HTTP or 
Protocol.HTTPS.

I can't say "problem solved" but this is interesting and confusing at the same 
time.
--
Timothy Aanerud

On Mon, Jun 29, 2009 at 9:18 AM, Timothy Aanerud  
wrote:

I haven't tried switching HTTP connectors. :-(

But, I did build a sanitized/stripped down example.  Unfortunately, my example 
does not fail like my application does.   One difference between my example is 
I'm only exchange data with one resource, In my actual application I'm sending 
two messages to two resources back-to-back before pausing.
--
Timothy Aanerud
taanerudataticonsulting.com  

 

On Mon, Jun 29, 2009 at 2:57 AM, Jerome Louvel  
wrote:

Hi Timothy,

 

Were you able to make progress on this front? 

 

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

 

 

De : Timothy Aanerud [mailto:taanerudATaticonsulting.com 
 ] 
Envoyé : vendredi 19 juin 2009 22:05


À : discuss@restlet.tigris.org

Objet : Re: Premature EOF / Broken Pipe

 

No, I haven't tried switching HTTP connectors. I get the same failures for both 
HTTP and HTTPS.
In another experiment, I changed the client message frequency to ~1 second 
intervals and at this rate on both
Windows XP and Fedora10/Linux show now problems with the server running on 
Fedora.

The various frequencies and failure rates: 
1 second == no problems
1.5 secon

RE: Resolve to Resources inside another Resource

[Jerome Louvel]

Hi Raymi,

Sorry, but I'm not sure I understood your question. On the server-side, you
could GET the resource at "http:///user/21"; by doing this:

   getContext().getClientDispatcher().get("http:///user/21";)

I hope this will help.

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é : dimanche 19 juillet 2009 17:59
À : discuss@restlet.tigris.org
Objet : Resolve to Resources inside another Resource

Hi all,

I'm evaluating restlet and have sort of a beginner question, but was unable
to find the answer here or in the documentation.

Suppose I want to add a resource via a POST of the following XML to the URL
http://.../items


  Some title
  http:///user/21


It's quite clear for me how I register a resource to handle this request.
But how do I resolve the REST URL (http:///user/21) for the referenced
user in the method that handles this POST? Is there a possiblity to directly
get a JAVA representation of this URL?

Thanks in advance,

raymi

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

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

RE: Help! -- Error handler isn't working

[Jerome Louvel]

Hi Schley,

I could open your link (404). By default, the exception doesn't appear in the 
browser to not expose too much internal details. You can customize the 
StatusService if needed. 

I agree it would be nice to have such an option available so I've updated this 
RFE:

"Return clear status description when exception caught"
http://restlet.tigris.org/issues/show_bug.cgi?id=852

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 : Schley Andrew Kutz [mailto:sak...@gmail.com] 
Envoyé : jeudi 23 juillet 2009 01:07
À : discuss@restlet.tigris.org
Objet : Re: Help! -- Error handler isn't working

Jerome,

Sorry about that (updated). Here is the ViewVC link to the file  - 
http://vangaea.svn.sourceforge.net/viewvc/vangaea/trunk/src/main/java/com/h9labs/vangaea/server/rest/BaseResource.java?view=markup
 
.

I've updated the code to take advantage of M4's doCatch handler.  
However, when I throw a ResourceException in the doInit() method, or  
any method, the ResourceException is not being displayed in the  
browser, and I was under the impression that it should.

Thanks!

-- 
-a

"Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former." -- Einstein

On Jul 21, 2009, at 2:53 AM, Jerome Louvel wrote:

> Hi Schley,
>
> Could you send us your project (or a snippet reproducing the issue)  
> and
> Restlet environment details (version, OS, etc.)? It should  
> definitely work.
>
> BTW, I suggest that you use more meaningful email title when you post,
> easier for tracking and searching in the archives.
>
> 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 : Schley Andrew Kutz [mailto:sak...@gmail.com]
> Envoyé : mardi 14 juillet 2009 21:52
> À : discuss@restlet.tigris.org
> Objet : Help!
>
> The StringRepresentation returned by 'public Representation handle()'
> is no longer appearing in the browser when I access my server.
>
> Here is an example:
>
> @Override
> public Representation handle()
> {
> if (true) return new StringRepresentation("Hello, world.");
> ...
>
> That should ALWAYS trump any other logic and show Hell, world. in the
> browser. Was a bug introduced to the Maven snapshot? Or do you think I
> could have farked myself somehow.
>
> -- 
> -a
>
> "Ideally, a code library must be immediately usable by naive
> developers, easily customized by more sophisticated developers, and
> readily extensible by experts." -- L. Stein
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23713
> 20
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372837

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

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

RE: Extension tunneling and matching route by extension

[Jerome Louvel]

Hi Rober,

The TunnelService is active for all your application. Unless you can split your 
resources in two logical applications, the only way is to manually code the 
behavior or to reuse the engine's TunnelFilter class located in 
"org.restlet.engine.application". 

Note that you will have to provide a special TunnelService instance where the 
"extensionTunnel" feature will be adjusted.

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 : Robert Binna [mailto:r.bi...@synedra.com] 
Envoyé : mardi 21 juillet 2009 11:31
À : discuss@restlet.tigris.org
Objet : Re: Extension tunneling and matching route by extension

Hi Jerome,

Thanks for your reply. If i switch off extension processing, matching  
urls together with extensions works well.
But the problem is that I have to do all of the functionality of the  
ExtensionsTunnel by Hand.
So I need both the TunnelService as well as url patterns that match by  
extension.

Or is there a way that I can active the ExtensionTunneling only for  
parts of my url space.

e.g.

/resources/. with extension tunneling
/static/ without extension tunneling

Kind regards,
 Robert


Am 21.07.2009 um 11:17 schrieb Jerome Louvel:

> Hi Robert,
>
> Did you try to switch off the extension processing in the  
> TunnelService? Use
> TunnelService#setExtensionsTunnel(false).
>
> 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 : Robert Binna [mailto:r.bi...@synedra.com]
> Envoyé : lundi 13 juillet 2009 12:46
> À : discuss@restlet.tigris.org
> Objet : Extension tunneling and matching route by extension
>
> Hi,
>
> I am developing a restlet based application and I am using the router
> restlet to dispatch to the target resources.
> My problem is, that after the tunnel service  has removed the
> extension, the rule that matches the url is no longer applicable.
>
> The code that is used is:
>
> router.attach("/js/", new Directory(context, directory));
> router.attach("/js/lang.{lang}.js", LanguageResource.class); //causes
> trouble
> Route route = router.attach("/js/{relurl}.html",
> HTMLResource.class); // matching on relurl is done via TYPE_URI_ALL,
> causes trouble too
>
> Is there a way to force the routing to respect the original url, and
> not the stripped one?
>
> Kind regards,
>   Robert
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23708
> 81
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372869

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

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

RE: Building the restlet modules in eclipse

[Jerome Louvel]

Hi Jim,

For GAE, we currently ship a special "org.restlet.gae.jar". Extensions not
included in this JAR haven't been tested with GAE yet, but some might work.

Thierry is finished the implementation an automatic porting mechanism that
will provide you a separate downloadable edition for GAE. It should be ready
for 2.0 M4. 

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 : Jim Alateras [mailto:jalate...@gmail.com] 
Envoyé : mercredi 22 juillet 2009 01:57
À : discuss@restlet.tigris.org
Objet : Building the restlet modules in eclipse

Hey all,

I've got a couple of questions

1. I am following the instructions on building restlet in eclipse
(http://wiki.restlet.org/developers/179-restlet/216-restlet.html 
) and am getting lots of these errors


Access restriction: The constructor ByteArrayDataSource(InputStream,  
String) is not accessible due to restriction on required library / 
System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ 
endorsed/mail.jar   DataSourceProvider.java org.restlet.ext.jaxrs/src/ 
org/restlet/ext/jaxrs/internal/provider line 75 Java Problem

Do I need to use a specific version of the library/jdk?

2. Has anyone deployed restlet framework on the Java GAE?

cheers


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

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

RE: Non-blocking application architecture quesiton

[Jerome Louvel]

Hi Evgeny,

The Jetty NIO connector don't expose NIO channels down the chain. So at the
Restlet level, we communicate with Jetty using streams so your approach will
work and leverage the NIO capabilities of Jetty.

However, it is possible to go further by using the Grizzly connector. In
this case, it can directly leverage ChannelRepresentations.

In all cases, the Representation subclasses are able to convert
automatically between BIO streams and NIO channels if necessary.

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 : news [mailto:n...@ger.gmane.org] De la part de Evgeny Shepelyuk
Envoyé : jeudi 23 juillet 2009 11:52
À : discuss@restlet.tigris.org
Objet : Non-blocking application architecture quesiton

Hello,

I have a question regarding architecture of NIO application.
My restlets are going to stream content to clients for a long time.
So connection between server and client will be long living.
I'm using Jetty a server connector with NIO jetty server.
On restlet side i'm extending OutputRepresentation and override write  
method to stream contetn to underlying client.
Is it true and i will get all advantages of NIO ?
Or i should extend ChannelRepresentation and use Java NIO channels, byte  
buffers to stream content ?


-- 
Regards,
Evgeny Shepelyuk

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

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

RE: FileClientHelper

[Jerome Louvel]

Hi Rémi,

 

It seems to me that Directory should indeed ignore your file because “001” and 
“bak” are unknown extensions. Could you enter an issue in the tracker?

 

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

 

 

 

 

De : remidewi...@gmail.com [mailto:remidewi...@gmail.com] De la part de Rémi 
Dewitte
Envoyé : jeudi 9 juillet 2009 17:40
À : discuss@restlet.tigris.org
Objet : Re: FileClientHelper

 

Hello,

Actually found a solution/hack, at application startup :
getMetadataService().addExtension("bak", 
MediaType.valueOf("application/backup"));

I am not sure it is the normal behavior...

Rémi

2009/7/9 Rémi Dewitte 

Hello,

With last trunk code, I would like the FILE client helper NOT to find 
"test.xml.001.bak" when I ask for "test.xml", how can I achieve this ?

Thanks,
Rémi

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

RE: Problem configuring spring ext in 2.0M3

[Jerome Louvel]

Hi Ryan,

I have added support for ServerResource in the Spring extension after 2.0
M3. If you try with a recent 2.0 snapshot (unstable), you should get it
working. If not, enter an issue as suggested by Rhett.

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 : Rhett Sutphin [mailto:rh...@detailedbalance.net] 
Envoyé : mardi 21 juillet 2009 19:44
À : discuss@restlet.tigris.org
Objet : Re: Problem configuring spring ext in 2.0M3

Hi Ryan,

On Jul 21, 2009, at 8:33 AM, webp...@tigris.org wrote:

> If anyone else has this problem, I got SpringBeanRouter working by  
> making my own subclass, like so: http://pastie.org/553359
>
> I guess this should really go into SpringBeanRouter and  
> SpringBeanFinder, so if the maintainers of the spring extension  
> would like I can post a patch with some unit tests.

You're correct: this is a bug in SpringBeanRouter's support for the  
new ServerResource base class.  Could you file an issue in the bug  
tracker?  If you submit a patch with tests, that would be great.   
Jerome will need to get a JCA ( http://www.restlet.org/community/contribute 
  ) from you before we can accept it.

If you don't want to go the JCA route, please still file the bug and  
I'll fix it myself.

Thanks,
Rhett

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

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

RE: GAE + GWT + Restlet 2.0 M3 + challenge response is null on server side

[Jerome Louvel]

Hi Lauri,

Thanks for sharing this workaround.

The current code sets the user and password given in ChallengeResponse on
the internal RequestBuilder that is used:
http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/com/google/gwt/http
/client/RequestBuilder.html#setPassword%28java.lang.String%29

Let's keep an eye on it. I suggest entering a bug report for it with your
detailed environment:
http://www.restlet.org/community/issues

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é : vendredi 24 juillet 2009 12:12
À : discuss@restlet.tigris.org
Objet : RE: GAE + GWT + Restlet 2.0 M3 + challenge response is null on
server side

Hi Jerome,

I made a workaround for this. I'm adding the authorization header manually
when building a Request using the following code:
Series headers = new
Form();
headers.add("Authorization", "Basic " + base64EncodedCredentials);
request.getAttributes().put("org.restlet.http.headers", headers);

Adding Authorization header by hand was prohibited in HttpConverter, so I
had to remove the authorization header check from there.

Best,
Lauri

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

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

RE: Re: REST in mobiles

[Jerome Louvel]

Hi Abdul,

J2ME has such a limited set of APIs that I highly doubt that Jersey would work 
there (you should ask them though). 

Android is a full featured Java-based OS for mobile (http://www.android.com/). 
Doesn't it work for you?

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é : mardi 21 juillet 2009 12:46
À : discuss@restlet.tigris.org
Objet : RE: Re: REST in mobiles

Hi, Thank you for your response How about JSR300 and jersey does it work with 
mobiles?

> Hi Abdul,
> 
> Restlet only works with Android on mobile phones, not J2ME.
> 
> One way to make a phone acts as a Web server is to send request as special
> SMS messages. See related RFE:
> 
> "Add SMS server for Android"
> http://restlet.tigris.org/issues/show_bug.cgi?id=828
> 
> 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 : feda abdul [mailto:o...@hotmail.com] 
> Envoyé : vendredi 17 juillet 2009 20:03
> À : discuss@restlet.tigris.org
> Objet : RE: Re: REST in mobiles
> 
> But I tried to run the simple hello World on mobile but I got problem that
> is getrVariants.add(new Variant MediaType.TEXT_PLAIN)) is not supported by
> J2me! How can I solve this problem
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23721
> 36

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

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

RE: Guidance on Atom/APP in Restlet

[Jerome Louvel]

Hi Tim,

 

Using an object serialization representation does reintroduce strong
coupling between a REST client and server. It should only be done for
optimization purpose, as an alternative to more reusable and interoperable
JSON / XML representations. 

 

But wait! XML and JSON do introduce coupling as you need to know their
structure in advance most of the time! If you want an even less coupling,
then looking towards RDF is a good idea but still you will need to
understand some ontologies...

 

With REST/HTTP you can deal with this issue in two ways:

 - standard representation formats such as HTML, Atom (to a certain extent),
PNG, etc.

 - content negotiation

 

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

 

 

De : tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de Tim
Peierls
Envoyé : mardi 21 juillet 2009 15:08
À : discuss@restlet.tigris.org
Objet : Re: Guidance on Atom/APP in Restlet

 

On Tue, Jul 21, 2009 at 4:39 AM, Jerome Louvel 
wrote:

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 serialization is used in
GWT-RPC but can be reused in a RESTful way. This isn't quite ready yet, but
hopefully for Restlet 2.0 M4, I'll have something more stable.

 

I've already said that this is very cool, but it does make we wonder ...
Isn't this sort of, um, cheating? A representation that is coupled to a
particular client/service pair? Another few steps over the edge and we're
back to RPC-style services.

 

I guess the saving grace is that Restlet makes it easy, or even trivial, to
provide other representations in addition to the one that's optimized for
common use, and RPC-style frameworks can't offer that at all.

 

 

 

As David mentioned, this could be complementary to exposing Atom
representations of your resources. Finally, I'm not sure if you need to
support the full AtomPub standard or just the Atom XML one.

 

Hmm, the wind is going out of my sails. I started by recognizing that
AtomPub seemed to be a natural fit for my domain, and now I'm looking at
JSON/serialized beans and "optional" plain Atom feeds. (Optional in the
sense that my main applications wouldn't need them,  because they'd be
happily talking JSON.)

 

Anybody have anything encouraging to say about why I shouldn't just stick
with my existing DWR application? (www.directwebremoting.org)

 

--tim

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