date:20090116

RE: media type adaptor

2009-01-16 Thread Cliff Binstock

Jerome,

 

I am using the standard content negotiation, and am declaring multiple 
variants.  The issue is that I have LOTS of variants (HTML, XML, Excel 
spreadsheets, and more), and sometimes the variant I return might have NOTHING 
to do with the content list requested (Excel, for example, is not in the IE or 
FF content request list).

 

I will look at the MetadataService rewrite, which might help.  However I don’t 
currently have a “general” rule (which I think is what the MetadataService 
remap might accomplish), but the type-to-return rules are determined by the 
requested URLs.  I will consider this, however, maybe I can (and should) make 
it more consistent.

 

Thanks for the pointing these items out.  I definitely will look at both the 
MetadataService and the TunnelService to see if I can better use the 
infrastructure.

 

Cliff Binstock
Coyote Reporting

  _  

From: Jerome Louvel [mailto:jerome.lou...@noelios.com] 
Sent: Friday, January 16, 2009 12:49 AM
To: discuss@restlet.tigris.org
Subject: RE: media type adaptor

 

Hi Cliff,

 

It seems like doing what you propose would overlap with the normal content 
negotiation which should be driven by client preferences.

 

If you want to return the same representation as both "application/xhtml+xml" 
and "text/xml", if can simply declare the two variants and return the same 
"technical" representation for each one of them, either via the current if/else 
if approach or in the near future via the representXhtml() and representXml() 
methods.

 

Also, in the MetadataService, the same extension (ex: "xml") can be mapped to 
several media types (ex: "text/xml" and "application/xml") so in this case, the 
representXml() method would match both.

 

Regarding the browser nonsense, we did implement a solution in the 
TunnelService that can automatically rewrite the preferences based on the user 
agent name (see the "userAgentTunnel" property).

 

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

 

  _  

De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] 
Envoyé : jeudi 15 janvier 2009 19:31
À : discuss@restlet.tigris.org
Objet : RE: media type adaptor

J�r�me,

 

Some more thoughts … from experience …

 

1.  Need a flag to determine if alternate representations are acceptable 
(Requester asked for HTML, but I don’t have that, and wish to return XML). 
2.  If alternate is acceptable, need a prioritized (ordered) list of 
acceptable variants (look for XHTML, then look for HTML, then look for XML).� 
You should probably have a default, but it should be easy to override. 
3.  If you feel like getting into the browser nonsense (and I’d understand 
if you didn’t), bypass/translate to another type.� For example, IE doesn’t 
behave kindly to XHTML return type.� Of course, any behavior here must be 
customizable (overridable). 

 

Cliff Binstock
Coyote Reporting

  _  

From: Jerome Louvel [mailto:jerome.lou...@noelios.com] 
Sent: Wednesday, January 14, 2009 10:14 AM
To: discuss@restlet.tigris.org
Subject: RE: media type adaptor

 

Hi all,

 

We have a similar plan in the tube!

 

"Faciliate Resource to Representation mapping"

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

 

The idea is to dynamically dispatch the represent(*), acceptRepresentation(*) 
and storeRepresentation(*) to the more specific versions if available like:

 

representXml(?) for an XML representation ("xml" being mapped in 
MetadataService like for file extensions)

representJson(?) for a JSON representation

...

 

This would handle the dispatching automatically while still allowing a manual 
dispatching by overriding the generic represent(*) method when more appropriate 
(and for backward compatibility).

 

How does it sound?

 

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

 

 

  _  

De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] 
Envoy� : mardi 13 janvier 2009 17:43
� : discuss@restlet.tigris.org
Objet : RE: media type adaptor

Taylor,

 

I have implemented a solution like this and I highly recommend it.  I actually 
have taken it one step further and bound the routes (and the implementation) 
dynamically:  there is very little Java code, mostly just XML-based 
configuration.  In the cases where configuration does not make sense, then I 
have subclasses that provide an implementation as your message implies.

 

I can tell you that you will want to pass in the request to the callback:  you 
don’t always need it, but sometimes you need some contextual information (see 
previous post about wanting the original route URI, for example).

 

Cliff Binstock
Coyote Reporting

  ___

Re: media type adaptor

2009-01-16 Thread Tim Peierls

While this is undeniably convenient, it deserves more thought and discussion
before accepting as part of 1.2. I don't think it's a good idea as it
stands.
Item 35 of Josh Bloch's Effective Java (2nd edition) is "Prefer annotations
to naming patterns". One of the great strengths of Java is its type-safety,
an important reason why Java is such a good choice for production web
services. Naming patterns rely on conventions that are invisible to the
compiler; they throw away the opportunity to enforce typing rules at compile
time. The use of metadata (annotations), by contrast, lets the compiler work
for you by catching type problems early.

I'm talking specifically about using method-level annotations instead of
method naming patterns in the case of Resource methods related to variant
representations. I'm not trying to take this line of reasoning any farther.
For example, while I'm not crazy about allow* and handle*, at least that's
in Handler, not Resource, and even there Restlet *does* define the standard
methods (Get/Put/Post/Delete/Head/Options) explicitly.

--tim

On Fri, Jan 16, 2009 at 9:05 AM, Jerome Louvel wrote:

>  To illustrate the new feature, here is the test resource class that I
> used in the unit test:
>
> *public* *class* AutoDetectResource *extends* Resource {
>
> *public* Representation representXml() {
> *return* *new* StringRepresentation("test",
> MediaType.*TEXT_XML*);
> }
>
> *public* Representation representHtmlEn() {
> *return* *new* StringRepresentation("test EN",
> MediaType.*TEXT_HTML*);
> }
>
> *public* Representation representHtmlFr() {
> *return* *new* StringRepresentation("test FR",
> MediaType.*TEXT_HTML*);
> }
>
> }
> No need in this case to override the constructor, to update the variants'
> list or to manually handle the dispatching!
>
>

Re: HttpRequest suggestion

2009-01-16 Thread Rémi Dewitte

Patch submitted ! :)

Rémi

On Wed, Jan 14, 2009 at 21:31, Jerome Louvel wrote:

>  Hi Rémi,
>
> This remark has been made in the past and we have a RFE for this pending:
>
> "Add Request#getForwardedAddresses() method"
> http://restlet.tigris.org/issues/show_bug.cgi?id=668
>
> If you have time to work on a patch that would be welcome! :)
>
>  Best regards,
> Jérôme 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é :* lundi 12 janvier 2009 17:34
> *À :* discuss@restlet.tigris.org
> *Objet :* HttpRequest suggestion
>
> Hello all,
>
> When using http forward, I would find more convenient to have the real
> client address using request.getClientInfo().getAddress() instead of the
> forwarder component.
>
> It means changing line 227 of HttpRequest from
> result.getAddresses().add(addresses[i].trim());
> to
> result.getAddresses().add(0,addresses[i].trim());
>
> What do you think ?
>
> Rémi
>

RE: Re: Browse a Directory from a web application inside jboss

2009-01-16 Thread Jerome Louvel

Hi Ruben,

It must be an issue with your component, here is a sample that works:

import org.restlet.Application;
import org.restlet.Component;
import org.restlet.Directory;
import org.restlet.Restlet;
import org.restlet.data.Protocol;

public class SpringDirectory extends Application {

@Override
public Restlet createRoot() {
return new Directory(getContext(), "file:///c:/templates/");
}

public static void main(String[] args) throws Exception {
// Create a new Restlet component
final Component component = new Component();
component.getServers().add(Protocol.HTTP, 9876);
component.getDefaultHost().attach(new SpringDirectory());
component.start();
}

}

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

-Message d'origine-
De : Ruben Hernando [mailto:pr-rherna...@informa.es] 
Envoyé : vendredi 16 janvier 2009 12:22
À : discuss@restlet.tigris.org
Objet : RE: Re: Browse a Directory from a web application inside jboss

Hello,

I created the Directory in that way and it worked, but when I start my server 
whows an error whith the first file:

GRAVE: The informa.rest.spring.resources.SpringDirectory class has no Restlet 
defined to process calls. Maybe it wasn't properly started.

And it doesn't serve the file (error 500). If I refresh the page in the browser 
it works.


public class SpringDirectory extends Application {

@Override
public Restlet createRoot() {
return new 
Directory(getComponent().getContext().createChildContext(), 
"file:///c:/templates/");
} 

I'm using 1.2-SNAPSHOT version.

Rubén Hernando

> This worked! Thanks for your time.
> Brian
> 
> Michael Terrington wrote:
> > Hi Brian,
> > 
> > I've been adding the FILE client connector by creating a new component
> > and feeding that to the restlet that requires it.  Like so:
> > 
> > Component component = new Component();
> > component.getClients().add(Protocol.FILE);
> > Directory directory = new
> > Directory(component.getContext().createChildContext(),
> > "file:///c:/");
> > directory.setListingAllowed(true);
> > router.attach("/files", directory);
> > 
> > BTW the createChildContext() is in 1.1 so if you are using 1.0 just
> > remove it.  There's also no need for the inner Application containing
> > the Directory.
> > 
> > Regards,
> > Michael.
> 
> -- 
> Brian E. Williams
> Senior Application Developer
> 
> The Archer Group
> 233 King Street
> Wilmington, DE 19801
> 
> w: 302.429.9120 x225
> f: 302.429.8720
> 
> http://www.archer-group.com

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

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

RE: WADL and JAX-RS

2009-01-16 Thread Jerome Louvel

Hi Paul,

There is no plan yet for such a feature. We do support this extensively over 
the Restlet API however. Feel free to enter a RFE for
this in our bug tracker.

JAX-RS 1.0 support has been pretty complete. Zillions of unit tests were 
written and should ensure a stable behavior.

Here is the list of issues opened on JAX-RS extension:
http://restlet.tigris.org/issues/buglist.cgi?subcomponent=JAX-RS+extension&issue_status=NEW&issue_status=STARTED&issue_status=REOPEN
ED

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 : Paul Austin [mailto:mail-li...@revolsys.com] 
Envoye : vendredi 16 janvier 2009 01:24
A : discuss@restlet.tigris.org
Objet : WADL and JAX-RS

I was wondering if there are any plans to add auto WADL generation for JAX-RS 
applications? Or is this already implemented in a
newer version than 1.1?

In general what is the current status of the JAX-RS support is it experimental 
or more ready for prime time?

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

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

RE: Re: SpringBeanRouter issues

2009-01-16 Thread Daniel Woo

I tried to test your snapshot but I got some maven issues (can not 
automatically download snapshots by Nexus proxy because the file name is not in 
xxx-1.2-SNAPSHOT, have to download/copy/rename a bunch of files to my local 
repo). After one hour fight with maven dependency and class not found issues, I 
gave up and revert to 1.1.1.

Anyway I did read through your code SpringBeanRouter and SpringBeanFinder, it 
seems your solution is smarter than mine and SpringBeanFinder is totally not 
affected :-)  I 99% believe your change should work. Once you guys release 1.2 
officially I will switch to 1.2 asap.

Thank you for your great work!

Best Regards,
Daniel


> Hi Daniel,
> 
> Thanks for sharing your experience and for the enhancement suggestion. 
> 
> I've just made the SpringBeanRouter implement ApplicationContextAware, using 
> the context received to instantiate the finders. Changes are checked in SVN 
> trunk.
> 
> However, I'm not sure however about injecting the SpringBeanFinder because we 
> need one instance per target resource bean...
> 
> Could you test the next snapshot and let me know if it work fine?
> 
> Best regards,
> Jérôme Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>  
> 
> -Message d'origine-
> De : Daniel Woo [mailto:daniely...@hotmail.com] 
> Envoyé : vendredi 9 janvier 2009 17:26
> À : discuss@restlet.tigris.org
> Objet : *SPAM(1.8)* RE: Re: SpringBeanRouter issues
> 
> one more thing, if you want to intercept MyResource.represent(Variant), that 
> won't work with Spring AOP (jdk proxy or cglib). Because this method is 
> called by Resource.handleGet()
> 
> You have to intercept Resource.handleGet()/Put()/Post()/Delete(), or use 
> static waver like aspectJ.
> 
> > I think you can make SpringBeanRouter implement ApplicationContextAware. I 
> > made it this way, the AOP interceptor successfully executed.
> > 
> > I changed very little to your SpringBeanRouter and SpringBeanFinder:
> > 
> > SpringBeanRouter: make it ApplicationContextAware, and holds an 
> > ApplicationContext. Each time createFinder() will pass that app context to 
> > SpringBeanFinder.
> > 
> > SpringBeanFinder：now the constructor accepts an application context instead 
> > of a beanFactory. Moreover, you actually can also make the beanFinder 
> > ApplicationContextAware, in that way, you don't have to hard code "new  
> > SpringBeanFinder(appContext, beanName)" anymore, you can even inject 
> > SpringBeanFinder to SpringBeanRouter, hence the SpringBeanFinder can be 
> > replaced by subclass written by the end user.
> > 
> > What do you think? It's at least useful to me because this solves my 
> > transaction and security issue with Spring.
> 
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1014009

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

RE: Patch to parameterize port numbers in JUnit tests

2009-01-16 Thread Jerome Louvel

Hi Rhett,

Thanks for the pointer. Actually I wanted to reuse a static Java member, so I 
relied on the FieldRetrievingFactoryBean class:







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] 
Envoye : mercredi 14 janvier 2009 22:31
A : discuss@restlet.tigris.org
Objet : Re: Patch to parameterize port numbers in JUnit tests

> For Spring it should be possible to inject the static value into the  
> bean property. I don't remember the exact syntax, but we can
> figure this out.

You can configure a PropertyPlaceholderConfigurer into the application  
context:

http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html

It resolves placeholders from either system properties or a configured  
property file / inline list.

Rhett

On Jan 14, 2009, at 1:59 PM, Jerome Louvel wrote:

> Hi Raif,
>
> That sounds like a useful thing to do. I was trying to apply the  
> patch but got issues with the paths of the patched files.
>
> Could you try to use SVN instead to generate it, starting at the  
> root of the SVN trunk instead?
>
> For Spring it should be possible to inject the static value into the  
> bean property. I don't remember the exact syntax, but we can
> figure this out. Any Spring wizard listening?
>
> 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name]
> Envoye : samedi 10 janvier 2009 07:48
> A : discuss@restlet.tigris.org
> Objet : Patch to parameterize port numbers in JUnit tests
>
> hello there,
>
> the JUnit tests (in org.restlet.test) have hard-wired port numbers  
> which may
> not suit every developer's environment.  this patch introduces a new
> property in the main build.xml, and injects at as a system environment
> variable.
>
> when more than one port is required, the property value is used as a  
> base;
> i.e. second port number is valueOf(property) + 1, etc.
>
> the only test i was not able to parametrize was the Spring test (and  
> its
> .xml file).
>
>
> cheers;
> rsn
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1024775

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

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

RE: Patch to parameterize port numbers in JUnit tests

2009-01-16 Thread Jerome Louvel

Hi Raif,

Thanks! Your patch has been applied in SVN trunk. I just need to fix the Spring 
config file now.

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

-Message d'origine-
De : Raif S. Naffah [mailto:s...@naffah-raif.name] 
Envoyé : jeudi 15 janvier 2009 09:14
À : discuss@restlet.tigris.org
Cc : Jerome Louvel
Objet : Re: Patch to parameterize port numbers in JUnit tests

hello Jerome,

i've attached a new version done with kdesvn instead of Eclipse (previous 
version).


On Thu January 15 2009 06:59:06 Jerome Louvel wrote:
> Hi Raif,
>
> That sounds like a useful thing to do. I was trying to apply the patch
> but got issues with the paths of the patched files.
>
> Could you try to use SVN instead to generate it, starting at the root of
> the SVN trunk instead?
>
> For Spring it should be possible to inject the static value into the bean
> property. I don't remember the exact syntax, but we can figure this out.
> Any Spring wizard listening?
>
> 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name]
> Envoye : samedi 10 janvier 2009 07:48
> A : discuss@restlet.tigris.org
> Objet : Patch to parameterize port numbers in JUnit tests
>
> hello there,
>
> the JUnit tests (in org.restlet.test) have hard-wired port numbers which
> may not suit every developer's environment.  this patch introduces a new
> property in the main build.xml, and injects at as a system environment
> variable.
>
> when more than one port is required, the property value is used as a
> base; i.e. second port number is valueOf(property) + 1, etc.
>
> the only test i was not able to parametrize was the Spring test (and its
> .xml file).
>
>
> cheers;
> rsn
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=10
>24775


cheers;
rsn

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

Re: maven snapshot

2009-01-16 Thread Thierry Boileau

Hi Daniel,

well, we were warned by users of Buckminster that our snapshot file 
names (it was "org.restlet-1.2-SNAPSHOT.jar ") were not correct and must 
include a time stamp plus an incremental number...
So we updated it...
Now, we understand that each repository must support several versions of 
Maven. So let's update it again.
Thanks for the report.

best regards,
Thierry Boileau
> today I want to try some new feature in snapshot, but the my Nexus server 
> does not pull Restlet 1.2 snapshot correctly.
> I took a look at the repository, 
> http://maven.restlet.org/org/restlet/org.restlet/1.2-SNAPSHOT/
>
> it shows 
> org.restlet-1.2-20090114.060036-4121.jar
> org.restlet-1.2-20090114.060036-4121.pom
>
> Do you think it's better to change the latest snapshot names to the following?
> org.restlet-1.2-SNAPSHOT.jar
> org.restlet-1.2-SNAPSHOT.pom
>
> eg, mojo did it this way:
> tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.jar
> tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.jar.sha1
> tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.pom
> tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.pom.sha1
> tomcat-maven-plugin-1.0-alpha-2-SNAPSHOT.jar
> tomcat-maven-plugin-1.0-alpha-2-SNAPSHOT.pom
>
> Otherwise maven users have to manually copy & rename them into their local 
> repo, right?
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1028645
>
>

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

maven snapshot

2009-01-16 Thread Daniel Woo

today I want to try some new feature in snapshot, but the my Nexus server does 
not pull Restlet 1.2 snapshot correctly.
I took a look at the repository, 
http://maven.restlet.org/org/restlet/org.restlet/1.2-SNAPSHOT/

it shows 
org.restlet-1.2-20090114.060036-4121.jar
org.restlet-1.2-20090114.060036-4121.pom

Do you think it's better to change the latest snapshot names to the following?
org.restlet-1.2-SNAPSHOT.jar
org.restlet-1.2-SNAPSHOT.pom

eg, mojo did it this way:
tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.jar
tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.jar.sha1
tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.pom
tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.pom.sha1
tomcat-maven-plugin-1.0-alpha-2-SNAPSHOT.jar
tomcat-maven-plugin-1.0-alpha-2-SNAPSHOT.pom

Otherwise maven users have to manually copy & rename them into their local 
repo, right?

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

maven snapshot

2009-01-16 Thread Daniel Woo

today I want to try some new feature in snapshot, but the my Nexus server does 
not pull Restlet 1.2 snapshot correctly.
I took a look at the repository, 
http://maven.restlet.org/org/restlet/org.restlet/1.2-SNAPSHOT/

it shows 
org.restlet-1.2-20090114.060036-4121.jar
org.restlet-1.2-20090114.060036-4121.pom

Do you think it's better to change the latest snapshot names to the following?
org.restlet-1.2-SNAPSHOT.jar
org.restlet-1.2-SNAPSHOT.pom

eg, mojo did it this way:
tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.jar
tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.jar.sha1
tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.pom
tomcat-maven-plugin-1.0-alpha-2-20081202.164509-1.pom.sha1
tomcat-maven-plugin-1.0-alpha-2-SNAPSHOT.jar
tomcat-maven-plugin-1.0-alpha-2-SNAPSHOT.pom

Otherwise maven users have to manually copy & rename them into their local 
repo, right?

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

RE: media type adaptor

2009-01-16 Thread Jerome Louvel

To illustrate the new feature, here is the test resource class that I used in 
the unit test:
public class AutoDetectResource extends Resource {

public Representation representXml() {
return new StringRepresentation("test", 
MediaType.TEXT_XML);
}

public Representation representHtmlEn() {
return new StringRepresentation("test EN", 
MediaType.TEXT_HTML);
}

public Representation representHtmlFr() {
return new StringRepresentation("test FR", 
MediaType.TEXT_HTML);
}

}

No need in this case to override the constructor, to update the variants' list 
or to manually handle the dispatching!
 
Best regards,
Jerome

  _  

De : Jerome Louvel [mailto:jerome.lou...@noelios.com] 
Envoyé : vendredi 16 janvier 2009 14:36
À : discuss@restlet.tigris.org
Objet : RE: media type adaptor


 
Hi Taylor,
 
I agree with you that this is an important core feature. What about if I tell 
you that I have just committed the support for represent*() methods in SVN 
trunk? :)
 
Here is the new paragraph in the Javadocs:
 
In addition, there is a simpler way to declare your variants and return the 
matching representations. For this, you just need to add public represent*() 
methods, where the '*' is replaced by a list of extensions in camel case. For 
example "representXmlFr()" would declare two variants: one with the "text/xml" 
media type and another with the "application/xml" media type. Both would 
declare a {...@link Language#FRENCH} language. In addition, those methods must 
return a {...@link Representation} instance and accept optional input parameter 
of the following classes: {...@link MediaType}, {...@link Variant}, {...@link 
CharacterSet}. Their value is provided from the selected variant to represent. 
Note that if several media type or character set extensions are detected, they 
will produce separate variants. However, several languages or encodings will 
produce only one list for each defined variant. The list of supported 
extensions and their matching metadata is provided by the application's 
{...@link MetadataService}. If needed, this feature can be turned off by 
calling {...@link #setDetectVariants(boolean)}.
 
Let me know if it works for you! 
 
Next step is to extend this feature to accept*Representation() and 
store*Representation() methods.
 
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com
 
 
  _  

De : Taylor Cowan [mailto:taylor_co...@yahoo.com] 
Envoyé : jeudi 15 janvier 2009 22:03
À : discuss@restlet.tigris.org
Objet : Re: media type adaptor


Jerome, 

that sounds good to me.  The extent to which Restlets solves content negation 
puts it head and shoulders above servlets and other web thingies.

My two cents is that's an area of priority, in comparison with all the planned 
integrations (lucene, semweb, etc.).  Also, Cliff's comments are good ones, 
sounds like they've been doing a lot of this and went through the weeds already.

Taylor


  _  

From: Cliff Binstock 
To: discuss@restlet.tigris.org
Sent: Thursday, January 15, 2009 12:30:52 PM
Subject: RE: media type adaptor



J�r�me,

 

Some more thoughts � from experience �

 

1.  Need a flag to determine if alternate representations are acceptable 
(Requester asked for HTML, but I don�t have that, and wish to return XML). 

2.  If alternate is acceptable, need a prioritized (ordered) list of 
acceptable variants (look for XHTML, then look for HTML, then look for XML).  
You should probably have a default, but it should be easy to override. 

3.  If you feel like getting into the browser nonsense (and I�d understand 
if you didn�t), bypass/translate to another type.  For example, IE doesn�t 
behave kindly to XHTML return type.  Of course, any behavior here must be 
customizable (overridable). 

 

Cliff Binstock
Coyote Reporting

  _  

From: Jerome Louvel [mailto:jerome.lou...@noelios.com] 
Sent: Wednesday, January 14, 2009 10:14 AM
To: discuss @restlet.tigris.org
Subject: RE: media type adaptor

 

Hi all,

 

We have a similar plan in the tube!

 

"Faciliate Resource to Representation mapping"

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

 

The idea is to dynamically dispatch the represent(*), acceptRepresentation(*) 
and storeRepresentation(*) to the more specific versions if available like:

 

representXml(?) for an XML representation ("xml" being mapped in 
MetadataService like for file extensions)

representJson(?) for a JSON representation

...

 

This would handle the dispatching automatically while still allowing a manual 
dispatching by overriding the generic represent(*) method when more appropriate 
(and for backward compatibility).

 

How does it sound?

 

Best regards,
J�r�me Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org

RE: media type adaptor

2009-01-16 Thread Jerome Louvel

Hi Taylor,
 
I agree with you that this is an important core feature. What about if I tell 
you that I have just committed the support for represent*() methods in SVN 
trunk? :)
 
Here is the new paragraph in the Javadocs:
 
In addition, there is a simpler way to declare your variants and return the 
matching representations. For this, you just need to add public represent*() 
methods, where the '*' is replaced by a list of extensions in camel case. For 
example "representXmlFr()" would declare two variants: one with the "text/xml" 
media type and another with the "application/xml" media type. Both would 
declare a {...@link Language#FRENCH} language. In addition, those methods must 
return a {...@link Representation} instance and accept optional input parameter 
of the following classes: {...@link MediaType}, {...@link Variant}, {...@link 
CharacterSet}. Their value is provided from the selected variant to represent. 
Note that if several media type or character set extensions are detected, they 
will produce separate variants. However, several languages or encodings will 
produce only one list for each defined variant. The list of supported 
extensions and their matching metadata is provided by the application's 
{...@link MetadataService}. If needed, this feature can be turned off by 
calling {...@link #setDetectVariants(boolean)}.
 
Let me know if it works for you! 
 
Next step is to extend this feature to accept*Representation() and 
store*Representation() methods.
 
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com
 
 
  _  

De : Taylor Cowan [mailto:taylor_co...@yahoo.com] 
Envoyé : jeudi 15 janvier 2009 22:03
À : discuss@restlet.tigris.org
Objet : Re: media type adaptor


Jerome, 

that sounds good to me.  The extent to which Restlets solves content negation 
puts it head and shoulders above servlets and other web thingies.

My two cents is that's an area of priority, in comparison with all the planned 
integrations (lucene, semweb, etc.).  Also, Cliff's comments are good ones, 
sounds like they've been doing a lot of this and went through the weeds already.

Taylor


  _  

From: Cliff Binstock 
To: discuss@restlet.tigris.org
Sent: Thursday, January 15, 2009 12:30:52 PM
Subject: RE: media type adaptor



J�r�me,

 

Some more thoughts � from experience �

 

1.  Need a flag to determine if alternate representations are acceptable 
(Requester asked for HTML, but I don�t have that, and wish to return XML). 

2.  If alternate is acceptable, need a prioritized (ordered) list of 
acceptable variants (look for XHTML, then look for HTML, then look for XML).  
You should probably have a default, but it should be easy to override. 

3.  If you feel like getting into the browser nonsense (and I�d understand 
if you didn�t), bypass/translate to another type.  For example, IE doesn�t 
behave kindly to XHTML return type.  Of course, any behavior here must be 
customizable (overridable). 

 

Cliff Binstock
Coyote Reporting

  _  

From: Jerome Louvel [mailto:jerome.lou...@noelios.com] 
Sent: Wednesday, January 14, 2009 10:14 AM
To: discuss @restlet.tigris.org
Subject: RE: media type adaptor

 

Hi all,

 

We have a similar plan in the tube!

 

"Faciliate Resource to Representation mapping"

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

 

The idea is to dynamically dispatch the represent(*), acceptRepresentation(*) 
and storeRepresentation(*) to the more specific versions if available like:

 

representXml(?) for an XML representation ("xml" being mapped in 
MetadataService like for file extensions)

representJson(?) for a JSON representation

...

 

This would handle the dispatching automatically while still allowing a manual 
dispatching by overriding the generic represent(*) method when more appropriate 
(and for backward compatibility).

 

How does it sound?

 

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

 

 

  _  

De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] 
Envoy� : mardi 13 janvier 2009 17:43
� : discuss @restlet.tigris.org
Objet : RE: media type adaptor

Taylor,

 

I have implemented a solution like this and I highly recommend it.  I actually 
have taken it one step further and bound the routes (and the implementation) 
dynamically:  there is very little Java code, mostly just XML-based 
configuration.  In the cases where configuration does not make sense, then I 
have subclasses that provide an implementation as your message implies.

 

I can tell you that you will want to pass in the request to the callback:  you 
don�t always need it, but sometimes you need some contextual information (see 
previous post

Re: How to set the SSLContextFactory in the Client

2009-01-16 Thread Bruno Harbulot

Hi Chris,

Bruno Harbulot wrote:
> Hi Chris,
> 
> christian.hai...@gmail.com wrote:
>> I use Restlet Version 1.1
>>
>> I tried it this way:
>>
>> Client client = new Client(new Context(), Protocol.HTTPS);
>> Context con = client.getContext();
>> Series param1 = con.getParameters();
>> param1.add("sslContextFactory","MySSLContextFactory");
>> 
>> where MySSLContextFactory has the base class 
>> com.noelios.restlet.util.SslContextFactory
>>
>> But it is not working that way. 
> 
> Can you clarify how it's not working?
> 
> 
> There's more documentation here:
> [1] http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet.html
> [2] http://wiki.restlet.org/docs_1.1/13-restlet/28-restlet/153-restlet.html
> 
> 
> There is a difference between using parameters and attributes when 
> setting the context (as mentioned in [1]).
> When passing the settings via parameters, "sslContextFactory" must be a 
> class name, and you should also pass whatever other parameters your 
> SslContextFactory expects (I'm not sure what they are in your case). 
> This is more or less what's described in [2] for PkixSslContextFactory. 
> Most of the "keyStore*" parameters also work for the 
> DefaultSslContextFactory.
> 
> 
> If you want to pass an SslContextFactory that has already been 
> configured (perhaps with more advanced options), you might want to pass 
> the instance via the "sslContextFactory" /attribute/ in the context, in 
> which case the value of the "sslContextFactory" /parameter/ will be ignored.
> 
> This could look like this, for example:
> 
> import org.jsslutils.sslcontext.PKIXSSLContextFactory;
> import org.jsslutils.sslcontext.trustmanagers.GsiWrappingTrustManager;
> 
> final PKIXSSLContextFactory sslContextFactory = new 
> PKIXSSLContextFactory(..., ..., ...);
> for (String crl :  ...) {
>   sslContextFactory.addCrl(crl);
> }
> 
> sslContextFactory.setTrustManagerWrapper(new 
> GsiWrappingTrustManager.Wrapper());
> 
> server.getContext().getAttributes().put("sslContextFactory",
>   new SslContextFactory() {
>   @Override
>   public SSLContext createSslContext() throws Exception {
>   return sslContextFactory.buildSSLContext();
>   }
> 
>   @Override
>   public void init(Series parameters) {
>   }
>   });


Sorry, I've just realised I had missed the point of the question: the 
client (whereas my example is for a server).

SslContextFactories are not currently supported on the client side. For 
more details, see: 
http://restlet.tigris.org/issues/show_bug.cgi?id=586#desc4

There are ways around this. You can create an SSLContextFactory with 
jSSLutils and create an SSLContext out of it.
If you're using Java 6 and the default Java connector, you can set this 
SSLContext using SSLContext.setDefault(...).
If you're using the Apache HTTP client connector, use the method 
described in issue #586, with this 
http://code.google.com/p/jsslutils/wiki/ApacheHttpClientUsage

In both cases, the settings will be global for all your client connectors.


Best wishes,

Bruno.

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

RE: Re: Browse a Directory from a web application inside jboss

2009-01-16 Thread postmaster

Hello,

I created the Directory in that way and it worked, but when I start my server 
whows an error whith the first file:

GRAVE: The informa.rest.spring.resources.SpringDirectory class has no Restlet 
defined to process calls. Maybe it wasn't properly started.

And it doesn't serve the file (error 500). If I refresh the page in the browser 
it works.


public class SpringDirectory extends Application {

@Override
public Restlet createRoot() {
return new 
Directory(getComponent().getContext().createChildContext(), 
"file:///c:/templates/");
}

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

RE: Re: Browse a Directory from a web application inside jboss

2009-01-16 Thread Ruben Hernando

Hello,

I created the Directory in that way and it worked, but when I start my server 
whows an error whith the first file:

GRAVE: The informa.rest.spring.resources.SpringDirectory class has no Restlet 
defined to process calls. Maybe it wasn't properly started.

And it doesn't serve the file (error 500). If I refresh the page in the browser 
it works.


public class SpringDirectory extends Application {

@Override
public Restlet createRoot() {
return new 
Directory(getComponent().getContext().createChildContext(), 
"file:///c:/templates/");
} 

I'm using 1.2-SNAPSHOT version.

Rubén Hernando

> This worked! Thanks for your time.
> Brian
> 
> Michael Terrington wrote:
> > Hi Brian,
> > 
> > I've been adding the FILE client connector by creating a new component
> > and feeding that to the restlet that requires it.  Like so:
> > 
> > Component component = new Component();
> > component.getClients().add(Protocol.FILE);
> > Directory directory = new
> > Directory(component.getContext().createChildContext(),
> > "file:///c:/");
> > directory.setListingAllowed(true);
> > router.attach("/files", directory);
> > 
> > BTW the createChildContext() is in 1.1 so if you are using 1.0 just
> > remove it.  There's also no need for the inner Application containing
> > the Directory.
> > 
> > Regards,
> > Michael.
> 
> -- 
> Brian E. Williams
> Senior Application Developer
> 
> The Archer Group
> 233 King Street
> Wilmington, DE 19801
> 
> w: 302.429.9120 x225
> f: 302.429.8720
> 
> http://www.archer-group.com

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

RE: Re: SpringBeanRouter issues

2009-01-16 Thread Daniel Woo

> > However, I'm not sure however about injecting the SpringBeanFinder  
> > because we need one instance per target resource bean...
> 
> This could be achieved by injecting the bean name (instead of an  
> instance) and then using the application context to retrieve instances  
> as needed.
> 
> That said, I much prefer the current style -- it allows you to change  
> the finder type by subclassing SpringBeanRouter and overriding  
> createFinder -- especially since you're going to have to modify the  
> prototype finders anyway (to give them the resource bean name).
> 
> Rhett
> 

Yes, I thought twice and realized you are right, the current implementation is 
good, since SpringBeanRouter is responsible for creating BeanFinder, we don't 
need to get Spring involved here.

Thanks,
Daniel

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

RE: media type adaptor

2009-01-16 Thread Jerome Louvel

Hi Cliff,
 
It seems like doing what you propose would overlap with the normal content 
negotiation which should be driven by client preferences.
 
If you want to return the same representation as both "application/xhtml+xml" 
and "text/xml", if can simply declare the two variants and return the same 
"technical" representation for each one of them, either via the current if/else 
if approach or in the near future via the representXhtml() and representXml() 
methods.
 
Also, in the MetadataService, the same extension (ex: "xml") can be mapped to 
several media types (ex: "text/xml" and "application/xml") so in this case, the 
representXml() method would match both.
 
Regarding the browser nonsense, we did implement a solution in the 
TunnelService that can automatically rewrite the preferences based on the user 
agent name (see the "userAgentTunnel" property).
 
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com

  _  

De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] 
Envoyé : jeudi 15 janvier 2009 19:31
À : discuss@restlet.tigris.org
Objet : RE: media type adaptor



J�r�me,

 

Some more thoughts … from experience …

 

1.  Need a flag to determine if alternate representations are acceptable 
(Requester asked for HTML, but I don’t have that, and wish to return XML). 

2.  If alternate is acceptable, need a prioritized (ordered) list of 
acceptable variants (look for XHTML, then look for HTML, then look for XML).� 
You should probably have a default, but it should be easy to override. 

3.  If you feel like getting into the browser nonsense (and I’d understand 
if you didn’t), bypass/translate to another type.� For example, IE doesn’t 
behave kindly to XHTML return type.� Of course, any behavior here must be 
customizable (overridable). 

 

Cliff Binstock
Coyote Reporting

  _  

From: Jerome Louvel [mailto:jerome.lou...@noelios.com] 
Sent: Wednesday, January 14, 2009 10:14 AM
To: discuss@restlet.tigris.org
Subject: RE: media type adaptor

 

Hi all,

 

We have a similar plan in the tube!

 

"Faciliate Resource to Representation mapping"

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

 

The idea is to dynamically dispatch the represent(*), acceptRepresentation(*) 
and storeRepresentation(*) to the more specific versions if available like:

 

representXml(?) for an XML representation ("xml" being mapped in 
MetadataService like for file extensions)

representJson(?) for a JSON representation

...

 

This would handle the dispatching automatically while still allowing a manual 
dispatching by overriding the generic represent(*) method when more appropriate 
(and for backward compatibility).

 

How does it sound?

 

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

 

 

  _  

De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] 
Envoy� : mardi 13 janvier 2009 17:43
� : discuss@restlet.tigris.org
Objet : RE: media type adaptor

Taylor,

 

I have implemented a solution like this and I highly recommend it.  I actually 
have taken it one step further and bound the routes (and the implementation) 
dynamically:  there is very little Java code, mostly just XML-based 
configuration.  In the cases where configuration does not make sense, then I 
have subclasses that provide an implementation as your message implies.

 

I can tell you that you will want to pass in the request to the callback:  you 
don’t always need it, but sometimes you need some contextual information (see 
previous post about wanting the original route URI, for example).

 

Cliff Binstock
Coyote Reporting

  _  

From: Taylor Cowan [mailto:taylor_co...@yahoo.com] 
Sent: Tuesday, January 13, 2009 7:12 AM
To: discuss@restlet.tigris.org
Subject: media type adaptor

 

I'm new to restlets and would like some feedback from the community on some 
experimentation.  Instead of if/else'ing through the list of variant types and 
calling the appropriate logic, I'd like reslets to do that for me.

The example "MediaType" below is similar to the restlet version, except that 
each enumeration overrides a call back, for example, the text/html type calls 
back to handleTextHTML().


TEXT_HTML("text/html", "HTML document") {
@Override
public Representation callBack(VariantHandler arg0) {
return arg0.handleTextHTML();
}
},

The application developer then extends a resource from BaseResource, and 
implements the methods they'd like to handle.  (like the AWT MouseEvent 
adaptors of old) The examples are not complete, I only implmented 4 media 
types.  The BaseResource gets the media type, converts to the appropriate 
exte

RE: Returning data after PUT/POST

2009-01-16 Thread Jerome Louvel

Hi Jean-Philippe,

Technically speaking, to return a representation from a PUT/POST you can just 
access to the response's entity from the
store/acceptRepresentation method:

getResponse().setEntity(myEntity);

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

-Message d'origine-
De : Karel Vervaeke [mailto:ka...@outerthought.org] 
Envoyé : vendredi 16 janvier 2009 09:25
À : discuss@restlet.tigris.org
Objet : Re: Returning data after PUT/POST

I'm not sure if this will help you, but in case of a PUT, you already
know the url, issuing a GET to the same url
should (by your implementation) return the same entity body you
presented in the PUT.  If you want to retrieve a 'more informative'
representation (i.e. including the 'internal' id), you could add a
query parameter to the url.

Alternatively (more appropriate in case of a POST) you can return a
201 Created status code [1] (with Location headers and url's in the
entity body) or a 202 Accepted status code

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2

HTH,
Karel

On Fri, Jan 16, 2009 at 2:37 AM, Jean-Philippe Steinmetz
 wrote:
> Hello everyone,
>
> I'm currently working on my first restlet application and have one big
> question. Typically when I want to persist some data I will not know certain
> information about it (i.e. the ID of the data). Instead of creating the
> object and searching for it I usually design my DAO to return the same
> object with the missing information filled in once it's been submitted to
> the persistence layer.
>
> I have noticed in building my restlet app that the storeRepresentation
> method does not return any type of data, only a status. Some of the clients
> that will be using the service would greatly benefit from the DAO style of
> data creation. So, how can I mimick this behavior in restlet so that a
> successful PUT returns the data back to the client as representation?
>
> Thanks for your time,
>
> Jean-Philippe
>

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

Re: Returning data after PUT/POST

2009-01-16 Thread Karel Vervaeke

I'm not sure if this will help you, but in case of a PUT, you already
know the url, issuing a GET to the same url
should (by your implementation) return the same entity body you
presented in the PUT.  If you want to retrieve a 'more informative'
representation (i.e. including the 'internal' id), you could add a
query parameter to the url.

Alternatively (more appropriate in case of a POST) you can return a
201 Created status code [1] (with Location headers and url's in the
entity body) or a 202 Accepted status code

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2

HTH,
Karel

On Fri, Jan 16, 2009 at 2:37 AM, Jean-Philippe Steinmetz
 wrote:
> Hello everyone,
>
> I'm currently working on my first restlet application and have one big
> question. Typically when I want to persist some data I will not know certain
> information about it (i.e. the ID of the data). Instead of creating the
> object and searching for it I usually design my DAO to return the same
> object with the missing information filled in once it's been submitted to
> the persistence layer.
>
> I have noticed in building my restlet app that the storeRepresentation
> method does not return any type of data, only a status. Some of the clients
> that will be using the service would greatly benefit from the DAO style of
> data creation. So, how can I mimick this behavior in restlet so that a
> successful PUT returns the data back to the client as representation?
>
> Thanks for your time,
>
> Jean-Philippe
>

RE: media type adaptor

Re: media type adaptor

Re: HttpRequest suggestion

RE: Re: Browse a Directory from a web application inside jboss

RE: WADL and JAX-RS

RE: Re: SpringBeanRouter issues

RE: Patch to parameterize port numbers in JUnit tests

RE: Patch to parameterize port numbers in JUnit tests

Re: maven snapshot

maven snapshot

maven snapshot

RE: media type adaptor

RE: media type adaptor

Re: How to set the SSLContextFactory in the Client

RE: Re: Browse a Directory from a web application inside jboss

RE: Re: Browse a Directory from a web application inside jboss

RE: Re: SpringBeanRouter issues

RE: media type adaptor

RE: Returning data after PUT/POST

Re: Returning data after PUT/POST

20 matches

Site Navigation

Mail list logo

Footer information