Re: changing the router's route list
Hello Jim What method on Router actually selects the Route? Have a look into Router.getNext(). The Route-s score itself in Route.score(..) best regards Stephan
RE: File extensions to select variants
Hi all, I agree with Stephan that only recognized extensions in the last URI segment should be cut. The feature could be deactivated on a per-application basis. Also, the supporting filter in the NRE packages could always be used manually, but from an API user point of view, it is easier to expose it via the TunnelService class. Keke, would that be fine? Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : jeudi 20 mars 2008 09:21 À : discuss@restlet.tigris.org Objet : Re: File extensions to select variants Hello keke, I am afraid that making this a default feature of application a bit dangerous. it will be possible, to disable this feature. I prefer, to disable it by default. Why not create a filter to do this? Users can then apply the filter if they want this feature. My first proposal was also to create a filter. But a lot of logic is already available in the TunnelFilter. I think the filter should only cut extension that are matched. best regards Stephan
RE: Reference with baseref and absolute path
Hi Jeroen, [...] I was expecting that calling getTargetRef() on a reference with an absolute path would clear the baseref. This is also how I understand it from the javadoc: This relative URI reference can then be resolved against a base reference via the getTargetRef() method which will return a new resolved Reference instance, an absolute URI reference with no base reference and with no dot-segments. Sounds like a bug to me. Further in the above get(reference) method, a Request is constructed, and request.getProtocol() gives an unexpected result: the implementation checks if there's a baseref, and returns this baseref's protocol. The fallback is to look at the protocol of the targetref itself. I would expect it to be just the other way around. In above scenario, dispatching of http://bar/foo.xml with base set to abc://foo/ would generate a request object that returns 'abc' as the protocol to use to get http://bar/foo.xml . Bug as well :( [...] So this leaves me wondering: Should getTargetRef() clear the baseref or do we have to rely on the verbose new Reference(getTargetRef().toString()) to do this ourselves ? It think we should fix the code as suggested by the Javadocs, unless I'm missing some other aspect. If all the unit tests pass after the change, then we should be pretty safe. Let's only change this in 1.1 branch only for now. If the last is the case, it is perhaps useful to provide a method like e.g. getCanonicalTargetRef() that gives the same result. And considering the request.getProtocol(): doesn't it make more sense to use the protocol of the targetref instead of the baseref when the targetref itself is absolute ? Yes, I think so. I'm of course willing to provide patches. Excellent, I'm looking forward to applying them. Make sure that you follow the contribution process indicated here: http://www.restlet.org/community/contribute Best regards, Jerome
RE: Specifying a specific client connector
Hi Dan, This is an advanced need but I can see how useful it can be. I've added an extra constructor to Client and Server that takes the qualified class name of the connector helper to use (such as com.noelios.restlet.ext.grizzly.HttpServerHelper). I didn't want to add it to other shortcut constructors to not overload the API and to highlight the fact that this is an advanced/special feature. Let me know if it helps. Code in SVN trunk. Best regards, Jerome -Message d'origine- De : Dan Diephouse [mailto:[EMAIL PROTECTED] Envoyé : mercredi 19 mars 2008 20:26 À : discuss@restlet.tigris.org Objet : Re: Specifying a specific client connector Imagine this scenario though - you have two threads creating clients with different implementations. If I have to explicitly set up engine properties then I have to make sure the threads execute sequentially. Am I missing something? It'd great if in the future there was a way to specify this information at a per-client or per-server level instead of via the global Engine. Dan Thierry Boileau wrote: Hello Dan, I think you can have a look at the following classe: com.noelios.restlet.test.BaseConnectorsTestCase. It is a base class that allows to cross server/client connectors and test each combination (see also GetTestcase in the same package). best regards, Thierry Boileau On Wed, Mar 19, 2008 at 7:28 PM, Dan Diephouse [EMAIL PROTECTED] wrote: I'm doing some experimentations with Restlet and have come up with a case were I wish to have multiple client connector implementations on the classpath. When I create the Client object I'd like to specify which implementation Restlet should use. Is there any way to do this? AFAICT from looking at the source code, Restlet just loops through the available ConnectorHelpers. Cheers, Dan -- Dan Diephouse MuleSource http://mulesource.com | http://netzooid.com -- Dan Diephouse MuleSource http://mulesource.com | http://netzooid.com
RE: Velocity MVC
Hi Ozhan, Yes, the handlePost() can specify a response entity directly: getResponse().setEntity(myFormRepresentation); You should also consider using the post(Representation entity) method (in v1.0) or acceptRepresentation(Representation) (in v1.1) instead of the lower-level handlePost() method. Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de ozhan Envoyé : mercredi 19 mars 2008 22:28 À : discuss@restlet.tigris.org Objet : Velocity MVC Hi, I made simple velocity template which includes a html form. It works well and i handle form paramters in the 'Resource:handlePost()' method. Is it possible to render same template without using getResponse().redirect???(...). Because i lost the model object if i refer the page to the new Resource.
Re: File extensions to select variants
Good for me :) On Thu, Mar 20, 2008 at 6:19 PM, Jerome Louvel [EMAIL PROTECTED] wrote: Hi all, I agree with Stephan that only recognized extensions in the last URI segment should be cut. The feature could be deactivated on a per-application basis. Also, the supporting filter in the NRE packages could always be used manually, but from an API user point of view, it is easier to expose it via the TunnelService class. Keke, would that be fine? Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : jeudi 20 mars 2008 09:21 À : discuss@restlet.tigris.org Objet : Re: File extensions to select variants Hello keke, I am afraid that making this a default feature of application a bit dangerous. it will be possible, to disable this feature. I prefer, to disable it by default. Why not create a filter to do this? Users can then apply the filter if they want this feature. My first proposal was also to create a filter. But a lot of logic is already available in the TunnelFilter. I think the filter should only cut extension that are matched. best regards Stephan -- Cheers, Keke - We paranoid love life
Series.getValues()
Sorry if this is a duplicate, but I never say my original message echo
to the list.
Begin forwarded message:
Date: March 19, 2008 4:19:32 PM PDT
To: discuss@restlet.tigris.org
Subject: Series.getValues()
This method, as written in Restlet 1.0.8, specifically this variant:
getValues(String name, String separator, boolean ignoreCase)
has room for improvement. Aside from the fact that the ignoreCase
parameter is not used, globbing the values together with a separator
is not that useful. I really want:
String[] getValues(String name)
with an implementation like:
public String[] getFormValues( String paramName ) {
final ListString temp = new LinkedListString();
for ( Parameter param : this )
if ( param.getName().equalsIgnoreCase( paramName ) )
temp.add( param.getValue() );
return temp.toArray( new String[ temp.size() ] );
}
- Paul
Spring + Restlet + Tomcat
I'm trying without much success to bootstrap a new project using both
Spring (2.5) and restlet(1.1-M2). The plan goes something like this;
* Restlet resources on the front end which interact with a service
layer. The service layer contains some business logic but mostly passes off
calls to a bunch of back end legacy systems. The goal is to expose those back
end systems as a uniform set of RESTful web services.
* I want to use Spring primarily for IoC, Aspects and JMX ease of
use. Plus being able to fairly easily add thread pools to my back end
adapters is appealing; all the usual Spring container arguments.
* I can't use the Restlet HTTP server and in all likelihood the
corporate powers will make us deploy on WebSphere for production but for now
I'm
trying to deploy Spting+Restlet as a WAR inside Tomcat.
I've read all I can find on the restlet site, the faq, the wiki and this list
about the various integration options but none are working. It seems there were
some previous integration strategies and some newer options. Various googling
has produced a confusing list of alternate approaches and I have to say the
restlet docs need a major boost.
I'd like to use Spring to inject the service layer into my Resources;
and in general to use its IoC injection across all the beans. Having
restlet config (router config, URL mapping etc) exposed (and manageable) by
Spring is nice.
I've had little success with Spring as the main container as all I get is the
NRE logFilter and a 404 from each of the resource URLs. My
web.xml looks like this;
context-param
param-nameorg.restlet.application/param-name
param-valueapplication/param-value
/context-param
context-param
param-nameorg.restlet.component/param-name
param-valuecomponent/param-value
/context-param
listener
listener-class
org.springframework.web.context.ContextLoaderListener
/listener-class
/listener
servlet
servlet-namespringRestletServlet/servlet-name
servlet-classcom.noelios.restlet.ext.spring.SpringServerServlet/servlet-
class
/servlet
servlet-mapping
servlet-namespringRestletServlet/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
With an applicationContext.xml that has the named beans component and
application as follows;
bean id=component class=org.restlet.ext.spring.SpringComponent
property name=defaultTarget ref=application/
property name=hosts
list
ref bean=virtualHost/
/list
/property
/bean
bean id=virtualHost class=org.restlet.ext.spring.SpringHost
property name=hostDomain
value=localhost/
property name=attachments
map
entry key=/ value-ref=application/
/map
/property
/bean
bean id=application
class=org.restlet.ext.spring.SpringApplication
constructor-arg ref=component/
property name=root
bean class=org.restlet.ext.spring.SpringRouter
constructor-arg ref=application/
property name=attachments
map
entry key=/policies
value=com.foo.policy.resource.PoliciesResource/
entry key=/policy/{policyId}
value=com.foo.policy.resource.PolicyResource/
/map
/property
/bean
/property
/bean
I also tried the other approach namely Restlet as the main container
but that's got it's own errors trying to get the Restlet Application to
load Spring properly and having unwired beans leading to various NPEs.
An earlier example did work but my app resources were 'Restlets' not
'Resources' which didn't feel right either.
I'd really appreciate if anyone has a complete end-to-end working
example of spring+restlet in tomcat with either approach, or if you can
spot a problem with the config shown above.
TIA,
-stephen
Re: Spring + Restlet + Tomcat
Hi Stephen, On Mar 20, 2008, at 10:27 AM, Stephen Mc Namara wrote: I'm trying without much success to bootstrap a new project using both Spring (2.5) and restlet(1.1-M2). The plan goes something like this; * Restlet resources on the front end which interact with a service layer. The service layer contains some business logic but mostly passes off calls to a bunch of back end legacy systems. The goal is to expose those back end systems as a uniform set of RESTful web services. * I want to use Spring primarily for IoC, Aspects and JMX ease of use. Plus being able to fairly easily add thread pools to my back end adapters is appealing; all the usual Spring container arguments. * I can't use the Restlet HTTP server and in all likelihood the corporate powers will make us deploy on WebSphere for production but for now I'm trying to deploy Spting+Restlet as a WAR inside Tomcat. I've read all I can find on the restlet site, the faq, the wiki and this list about the various integration options but none are working. It seems there were some previous integration strategies and some newer options. Various googling has produced a confusing list of alternate approaches and I have to say the restlet docs need a major boost. This is at least partially my fault. I promised documentation for how to use RestletFrameworkServlet and SpringBeanRouter/Finder, but have not delivered them yet. I'd like to use Spring to inject the service layer into my Resources; and in general to use its IoC injection across all the beans. Having restlet config (router config, URL mapping etc) exposed (and manageable) by Spring is nice. This is how I use it today. I'd really appreciate if anyone has a complete end-to-end working example of spring+restlet in tomcat with either approach, or if you can spot a problem with the config shown above. If you'd like an end-to-end working application of moderate complexity, you can look at Patient Study Calendar (PSC): https://svn.bioinformatics.northwestern.edu/studycalendar/trunk/ It is the open source clinical research app I developed the aforementioned adapter classes for. It is primarily a Spring-MVC webapp, with Spring IoC connecting all the layers. The RESTful API was added after most of the application functionality was in place, so it is somewhat similar to your situation. In particular, I think you'll want to look at https://svn.bioinformatics.northwestern.edu/studycalendar/trunk/src/main/webapp/WEB-INF/restful-api-servlet.xml which is the spring configuration file for the RestletFrameworkServlet (using SpringBeanRouter) and https://svn.bioinformatics.northwestern.edu/studycalendar/trunk/src/main/java/edu/northwestern/bioinformatics/studycalendar/restlets/ which contains all the Resource implementations. PSC's not as clean as an example written specifically for demonstration, but hopefully it can get the point across for now. Rhett
