RE: Restlet and OSGi Issues

[David Fogel]

Hi Jerome-

Let me first say that I wasn't trying to criticize the timeliness of
your answers (in fact I feel that the Restlet project is one of the
better-supported open-source projects out there, because of your (and
Theirry) presence on the discussion list, as well as your diligence in
keeping the Issues up to date.  I was lamenting the small number of
users of Restlet who seem to be using it in an OSGi environment.  I hope
we can all change that!  With respect to commercial support, well, I
promise to purchase support if our current project using Restlet ends up
generating any significant income for us :-)

To continue the discussion (and thanks again for taking a look at these
things):

Regarding the Restlet bundle manifest:

Thanks for the fix.  I think you're still missing javax.xml.xpath, which
you import in the file DomRepresentation.java.

In general, I'd suggest that you test OSGi-related features of Restlet
outside the eclipse environment.  When you launch an OSGi target inside
eclipse, there are differences with what classes are available by
default from an independent OSGi launch- I'm not sure why. 
Additionally, there are differences in which packages can be expected to
be auto-exported from the framework bundle between JDK 1.5 and JDK 1.6. 
 Testing outside of eclipse doesn't mean not using equinox, it just
means that you have to start equinox from outside of eclipse.  Despite
their stated goals, Eclipse's PDE environment is clearly more tuned
towards developing Eclipse plugins, and sometimes that bias causes
problems.

Regarding connectors and the missing bundle Activator:

Over the weekend I finally discovered the missing Activator, and I was
able to get the Jetty and Simple connectors working in my OSGi
environment.  What was particularly confusing was that the result of the
way this activator works means that there is now a bundle load-order
dependency issue for Restlet.  Depending on whether the ext bundle is
resolved at the time that your application instantiates a Component or
Server, your application will get either the internal connector or the
ext connector.  I discovered that restarting my application bundle would
result in getting the desired ext connector.

In your new OSGi Deployment page, you suggest setting the startlevel of
the restlet bundle to be lower (earlier) than other bundles.  This will
work (although there are still scenarios where it won't work due to the
allowed dynamism of OSGi- I could install and start the restlet bundle
and my bundle, and then after I could install the extension, and it
would be too late) but it is against OSGi best-practices to rely on
bundle start order in this manner.  see, e.g., this blog post:

http://www.osgi.org/blog/2009/02/ordering-get-over-it.html

I think that while dynamic extension discovery may be appropriate (or at
least convenient) for non-osgi environments, that in OSGi containers it
would be better to make the dependency more explicit.  It might be
better to have, at Component creation time, a mechanism to specify the
extension Helper class.  If this was a parameter that actually took a
Class instance, instead of a class name, this would be good because it
would force the user to explicitly include a Import-Package line on
their bundle specifying the ext bundle.  Then there wouldn't be any
issues about having _more than one_ restlet connector extension active
in the OSGi container- they would all be hooked up be explicit bundle
dependency management.

Thanks again, 
-Dave Fogel

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

RE: Re: Why does the Restlet class have lifecycle methods?

[David Fogel]

Hi Jerome-

I think that your plan sounds reasonable.  But I have some general thoughts 
on the issue:

Have you considered simply removing the Restlet life-cycle methods 
entirely?  Looking at the code, it seems that most included Restlet 
sub-classes don't have any life-cycle state, and therefor don't override 
these methods.  The main Restlet classes that do are Component and 
Application.   Since I imagine that Application instances rarely contain 
other Application instances, and that most Applications are contained 
directly by a Component or a VirtualHost, you could special-case the 
handling of those classes and remove start/stop from the restlet interface.  
Another alternative would be to us a separate optional interface, e.g. 
"StartStopable" or "LifecycleEnabled", and write general restlet code that 
checks for those interfaces.

One of the reasons I suggest this is that I've had experience writing 
hierarchical component model library APIs (as part of several web/GUI 
frameworks), and my experience was that the combination of component 
life-cycles and hierarchical containment (tree-like structures) can cause 
an explosion of complexity for the framework code, as well as increased 
complexity for any user's extensions.

Additionally, I suspect that many Restlet users will already be using some 
other form of life-cycle management.  Spring framework (as well as other 
dependency-injection libraries) in part manage the lifecycle of the 
beans/pojos that the create.  And environments like OSGi specify 
life-cycle at the module or "service" level.  A user of restlet may well be 
faced with many layers in which to potentially write life-cycle code.

If you feel that life-cycle methods are necessary, then my thought is that 
you should provide _very_ explicit documentation on what the contracts 
are around these life-cycle states, and what expectations the framework 
will have for any user-supplied Restlet subclasses, especially regarding 
the _interactions_ between lifecycle state and other behavior.  For 
instance, should a Restlet return an error status if it's "handle" method is 
called when it is in the "STOPPED" state?  Can a STOPPED restlet be 
re-started by the framework?  How does the starting/stopping interact 
with concurrent access?  How does the availability of the Context object 
change depending on lifecycle?  etc.

thanks,
   -Dave Fogel

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

Re: Testing RESTful Web Services built with Restlet

[Mark Derricutt]

We're using Concordion ( http://www.concordion.org/ ) - I keep meaning
to write up a blog post or two on my usage ( which since I'm giving
another talk on Corcordion in a week or so, I think I might do that
soon ).

...and then Buffy staked Edward.  The End.

On Tue, Mar 10, 2009 at 7:45 AM, Jerome Louvel
 wrote:
> Hi Sean,
>
> Have you considered Fitnesse?
> http://fitnesse.org/
>
> It's a wiki based acceptance test framework. Check their service fixture as
> well:
> http://servicefixture.sourceforge.net/
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -Message d'origine-
> De : webp...@tigris.org [mailto:webp...@tigris.org]
> Envoyé : mercredi 4 mars 2009 18:41
> À : discuss@restlet.tigris.org
> Objet : Testing RESTful Web Services built with Restlet
>
> I am looking for good ideas for testing RESTful web services built using
> Restlet. We have done obvious: JMeter, JUnit, and some integration testing.
>
> I'd like more automated tools that testers could use (possibly with the help
> of developers) that specifically address REST. The approaches I mentioned
> above are ad hoc in that sense.
>
> Thanks,
> Sean
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=12677
> 84
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1298352
>

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

RE: VirtualHost can't match on port number

[Jerome Louvel]

David,

Thanks for keeping us updated. 
I'm sure this will be useful to other readers facing a similar issue.

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

-Message d'origine-
De : David Fogel [mailto:carrotsa...@gmail.com] 
Envoyé : lundi 9 mars 2009 19:10
À : discuss@restlet.tigris.org
Objet : RE: VirtualHost can't match on port number

Hi Jerome, Thierry-

After spending some time in my debugger I've found my problem:

The main difference between my code and the Thierry's test code is that I
was setting host names on the virtual hosts (since this is how I needed to
deploy them).  In order to test this setup on my local machine, I use an
HTTP testing tool called "Http Client" ( http://ditchnet.org/httpclient/ ,
not to be confused with apache httpclient).  This tool allows you to
customize http requests and view the full response headers, etc).  It has a
feature that allows the user to add custom headers.  I was using this
feature to add custom "Host" headers, so that I could test the routing to my
different virtual hosts.

My error was that I didn't include the port number in the Host header value.

For example, I wrote:

Host: a.site.com

instead of:

Host: a.site.com:

I ommitted it because I already had the port specified in the address URI:

http://localhost:/path/to/resource/

But according to the HTTP spec, the Host header field, if present (and if
the Request-URI is not an absolute URI), should provide the port number.

So, because I was omitting the port number from the Host field, the Restlet
Request did not contain a port number.  (Presumably because the internal
server assumes it will be there if the Host header is present).

When using Virtual Hosts without setting host names (as in Thierry's
example), this isn't an issue.  But it also appears that in the absence of a
Host header, that the internal server WILL have a port number in the
Request, which I assume it fills in by looking at the internal
ServerSocket/Connector port number.

Perhaps the internal server should use this socket port number as a fallback
(instead of the scheme default port number)?  

Anyhow, sorry for the false alarm, and thanks for looking in to it!

- Dave Fogel

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

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

RE: Client objects are sharing connections

[Jerome Louvel]

Hello,

You might want to switch to our HTTP client based on Apache HTTPClient. It
also has a "readTimeOut" property.
 
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é : lundi 9 mars 2009 18:58
À : discuss@restlet.tigris.org
Objet : RE: Client objects are sharing connections

Hi Jerome.  

I have been using the net HTTP client.  I did some looking into the source
code, and I've found that the read timeout is set in the URLConnection
class.  This means that this is not a restlet issue, but instead it's an
issue with the URLConnection class (or more likely, I'm doing something
wrong when using the URLConnection class).

I'm still looking into it, but it definitely is not a restlet issue.

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

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

RE: File upload - as stream

[Jerome Louvel]

Hi guys,

We have also made usage of the stream API easier in Restlet 1.2 development
trunk in case you can use it. Otherwise it is pretty straightforward.
 
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 : David Bordoley [mailto:bordo...@gmail.com] 
Envoyé : lundi 9 mars 2009 19:42
À : discuss@restlet.tigris.org
Objet : Re: File upload - as stream

Apache File Upload supports a stream API. (see
http://commons.apache.org/fileupload/streaming.html) You should be able to
use it with RestletFileUpload.

dave

On Sun, Mar 8, 2009 at 10:41 AM, Matt Rutherford  wrote:
> Hi.
>
> Is there a way to receive a file element from an html form without 
> storing it to disk?
>
> I will be storing the file directly into a DB so no need to have it on 
> disk anywhere.
>
> Would be nice to just stream bytes to the LargeObject.write() Postgres 
> JDBC method.
>
> Sorry if this is a silly question, I'm a (enthusiastic) beginner with 
> this stuff. Any guidance much appreciated.
>
> Thanks!
>
>

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

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

Re: File upload - as stream

[David Bordoley]

Apache File Upload supports a stream API. (see
http://commons.apache.org/fileupload/streaming.html) You should be
able to use it with RestletFileUpload.

dave

On Sun, Mar 8, 2009 at 10:41 AM, Matt Rutherford  wrote:
> Hi.
>
> Is there a way to receive a file element from an html form without storing
> it to disk?
>
> I will be storing the file directly into a DB so no need to have it on disk
> anywhere.
>
> Would be nice to just stream bytes to the LargeObject.write() Postgres JDBC
> method.
>
> Sorry if this is a silly question, I'm a (enthusiastic) beginner with this
> stuff. Any guidance much appreciated.
>
> Thanks!
>
>

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

RE: Testing RESTful Web Services built with Restlet

[Jerome Louvel]

Hi Sean,

Have you considered Fitnesse?
http://fitnesse.org/

It's a wiki based acceptance test framework. Check their service fixture as
well:
http://servicefixture.sourceforge.net/

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


-Message d'origine-
De : webp...@tigris.org [mailto:webp...@tigris.org] 
Envoyé : mercredi 4 mars 2009 18:41
À : discuss@restlet.tigris.org
Objet : Testing RESTful Web Services built with Restlet

I am looking for good ideas for testing RESTful web services built using
Restlet. We have done obvious: JMeter, JUnit, and some integration testing. 

I'd like more automated tools that testers could use (possibly with the help
of developers) that specifically address REST. The approaches I mentioned
above are ad hoc in that sense.

Thanks,
Sean

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

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

Re: Integrating WADL and Spring

[David Bordoley]

It would be nice if you could allow more fine grain configuration
support via WADL, including adding Guards to resources, configuring
what methods and variants a resource supports via WADL etc. I added
some technical suggestions in the bug itself.

dave

On Mon, Mar 9, 2009 at 10:02 AM, Jerome Louvel
 wrote:
> Hi all,
>
> This is a good idea indeed. I've made a first step by updating
> WadlApplication to make it easy to customize the way resources are created
> based on the WADL resource descriptor, 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é : dimanche 8 mars 2009 03:07
> À : discuss@restlet.tigris.org
> Objet : Re: Integrating WADL and Spring
>
> Hi David,
>
> On Mar 6, 2009, at 4:10 PM, David Bordoley wrote:
>
>> On Fri, Mar 6, 2009 at 11:32 AM, Rhett Sutphin
>>  wrote:
>>
>>> This would be an RFE (at least, I'm not aware of any way to get it to
>>> work currently).  I'm curious about how you would tie the resources
>>> in your application context to the WADL.  Would you add a custom
>>> attribute for the spring bean id?  Is there a WADL feature which
>>> would help with this?  I'm not that familiar with it.
>>>
>>> Rhett
>>
>> Hi,
>>
>> The current way WADL works in Restlet is to require implementors to
>> specify the class of the resource you want to map a WADL resource to
>> using the resource's id attribute. You then pass the the WADL xml as a
>> constructor argument to a WadlComponent or WadlApplication. You can
>> see an example of this in org.restlet.test.YahooSearch.wadl (omitting
>> the details in the example below):
>>
>> 
>>  http://api.search.yahoo.com/NewsSearchService/V1/";>
>>    > path="newsSearch">
>>    
>>  
>> 
>>
>> It would be cool if you could do something similar but instead of
>> passing a Resource class (and be stuck using the default constructor
>> etc.), instead use a Spring Bean id as the resource id in WADL, and
>> have restlet use spring to wire all the resources together, thus
>> getting all the benefits of IOC, while also being able to more
>> explicitly state your resource interface in a standard method.
>>
>> Anyway i can open an RFE if necessary, but I wanted to ask on the list
>> first.
>
> This is a good idea.  I think the implementation might be more generic than
> just spring support, so I went ahead and entered the RFE against the WADL
> component:  http://restlet.tigris.org/issues/show_bug.cgi?id=756
>
> Thanks,
> Rhett
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=12864
> 20
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1297634
>

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

RE: VirtualHost can't match on port number

[David Fogel]

Hi Jerome, Thierry-

After spending some time in my debugger I've found my problem:

The main difference between my code and the Thierry's test code is that I 
was setting host names on the virtual hosts (since this is how I needed to 
deploy them).  In order to test this setup on my local machine, I use an 
HTTP testing tool called "Http Client" ( http://ditchnet.org/httpclient/ , 
not to be confused with apache httpclient).  This tool allows you to 
customize http requests and view the full response headers, etc).  It has a 
feature that allows the user to add custom headers.  I was using this 
feature to add custom "Host" headers, so that I could test the routing 
to my different virtual hosts.

My error was that I didn't include the port number in the Host header value. 
For example, I wrote:

Host: a.site.com

instead of:

Host: a.site.com:

I ommitted it because I already had the port specified in the address URI:

http://localhost:/path/to/resource/

But according to the HTTP spec, the Host header field, if present (and if 
the Request-URI is not an absolute URI), should provide the port number.

So, because I was omitting the port number from the Host field, the 
Restlet Request did not contain a port number.  (Presumably because 
the internal server assumes it will be there if the Host header is present).

When using Virtual Hosts without setting host names (as in Thierry's 
example), this isn't an issue.  But it also appears that in the absence 
of a Host header, that the internal server WILL have a port number in 
the Request, which I assume it fills in by looking at the internal 
ServerSocket/Connector port number.

Perhaps the internal server should use this socket port number as a 
fallback (instead of the scheme default port number)?  

Anyhow, sorry for the false alarm, and thanks for looking in to it!

- Dave Fogel

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

Re: Random Grizzly IOException

[Jeanfrancois Arcand]

Salut,

Jerome Louvel wrote:
> Hi Bruce,
> 
> Beautiful! I think that our Grizzly is finally going to be ready for prime
> time. The fix has been applied to both SVN trunk and 1.1 branch.
> 
> Thierry is going to publish some updated benchmarks for Restlet 1.1 very
> soon. Very timely!! :)
> 

This is great! Apology for not helping that much...we are swamped by our 
own community. But I will eventually look at the code and see where 
improvement (if any) can be made. I will be in EU in a couple of weeks 
so it might be the perfect time to work on it.

A+

-- Jeanfrancois


> 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 Bruce Lee
> Envoyé : vendredi 6 mars 2009 00:22
> À : discuss@restlet.tigris.org
> Objet : Re: Random Grizzly IOException
> 
> Jerome Louvel  noelios.com> writes:
> 
>  >
>  >
>  > Hi Bruce,
>  >
>  > Great news!
>  >
>  > Regarding the 40s delay I'm puzzled... Did you monitor the state of
> sockets?
>  > Are they all closed in a timely manner?
>  >
>  > Did you try using a profiler to detect which part of the code actually  >
> causes the delay?
>  >
>  > Best regards,
>  > Jérôme Louvel
>  > --
>  > Restlet ~ Founder and Lead developer ~ http://www.restlet.org  > Noelios
> Technologies ~ Co-founder ~ http://www.noelios.com  >
> 
> Hi Jerome,
> 
> Sorry I finally got some time to dig into this problem again and I think
> I've found the cause of the round time delay in 1.1.3.
> 
> In the ByteUtils, there's a SelectorFactory which is used when NIO
> selectablechannel is used. Notice that the factory limits the total number
> of active selectors to 20, and if the pool ever runs empty, it'll wait
> maximum of 2 periods of timeout (5s) before giving up. So the blocking we
> are seeing is coming from this piece of code. (10s, 20s, 30s
> etc..)
> 
> The fix is relatively simple, since the selector (and selectionKey) is only
> acquired in the NbChannelOutputStream when the channel is not available, the
> code should release the selector at the finally block of the doWrite method
> instead of waiting for the channel.close(). This will ensure that the
> limited number of selector is never kept for a long period of time.
> 
> Ex:
> } finally {
>   this.bb.clear();
>   release(this.selector, this.selectionKey); }
> 
> With this piece of code change, I was able to run the following test code
> with 100 burst request at the same time without any problem.
> 
> import java.io.BufferedReader;
> import java.io.InputStreamReader;
> 
> import org.restlet.Component;
> import org.restlet.Restlet;
> import org.restlet.data.MediaType;
> import org.restlet.data.Protocol;
> import org.restlet.data.Request;
> import org.restlet.data.Response;
> 
> public class Test2 {
> 
>   private static Component component = new Component();
> 
>   public static void main(String[] args) throws Exception {
> 
>   // Create a new Restlet component and add a HTTP server
>   // connector to it
>   component.getServers().add(Protocol.HTTP, 1234);
> 
>   // Print the requested URI path
>   StringBuffer message = new StringBuffer();
>   // setup a response with 80k
>   int size = 8;
>   char c = 'c';
>   for (int i = 0; i < size; i++) {
>   message.append(c);
>   }
>   final String s = message.toString();
>   
>   // Create a new tracing Restlet
>   Restlet restlet = new Restlet() {   
>   @Override
>   public void handle(Request request, Response
> response) {
>   response.setEntity(s, MediaType.TEXT_PLAIN);
>   }
>   };
> 
>   // Then attach it to the local host
>   component.getDefaultHost().attach("/", restlet);
> 
>   // Now, let's start the component!
>   // Note that the HTTP server connector is also automatically
>   // started.
>   component.start();
> 
>   BufferedReader in = null;
>   String line;
>   in = new BufferedReader(new InputStreamReader(System.in));
>   while (true) {
>   System.out.print("> ");
>   System.out.flush();
>   line = in.readLine();
>   if (line.startsWith("quit") ||
> line.startsWith("exit")) {
>   // quits the test client
>   break;
>   }
>   }
> 
>   component.stop();
>   }
> 
> }
> 
> Regards,
> 
> --
> http://restlet.tigris.org/

RE: Random Grizzly IOException

[Jerome Louvel]

Salut Jean-Francois!

You did help a lot already to get this connector bootstrapped. If you can
find time look at the code for any optimization possible would be really
cool. 

Also, Thierry will get in touch with you if anything special occurs during
his new benchmark. 

Thanks,
Jerome 

-Message d'origine-
De : jeanfrancois.arc...@sun.com [mailto:jeanfrancois.arc...@sun.com] 
Envoyé : lundi 9 mars 2009 19:07
À : Jerome Louvel
Cc : 'discuss'
Objet : Re: Random Grizzly IOException

Salut,

Jerome Louvel wrote:
> Hi Bruce,
> 
> Beautiful! I think that our Grizzly is finally going to be ready for 
> prime time. The fix has been applied to both SVN trunk and 1.1 branch.
> 
> Thierry is going to publish some updated benchmarks for Restlet 1.1 
> very soon. Very timely!! :)
> 

This is great! Apology for not helping that much...we are swamped by our own
community. But I will eventually look at the code and see where improvement
(if any) can be made. I will be in EU in a couple of weeks so it might be
the perfect time to work on it.

A+

-- Jeanfrancois


> 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 Bruce Lee
> Envoyé : vendredi 6 mars 2009 00:22
> À : discuss@restlet.tigris.org
> Objet : Re: Random Grizzly IOException
> 
> Jerome Louvel  noelios.com> writes:
> 
>  >
>  >
>  > Hi Bruce,
>  >
>  > Great news!
>  >
>  > Regarding the 40s delay I'm puzzled... Did you monitor the state of
> sockets?
>  > Are they all closed in a timely manner?
>  >
>  > Did you try using a profiler to detect which part of the code actually
>
> causes the delay?
>  >
>  > Best regards,
>  > Jérôme Louvel
>  > --
>  > Restlet ~ Founder and Lead developer ~ http://www.restlet.org  >
Noelios
> Technologies ~ Co-founder ~ http://www.noelios.com  >
> 
> Hi Jerome,
> 
> Sorry I finally got some time to dig into this problem again and I think
> I've found the cause of the round time delay in 1.1.3.
> 
> In the ByteUtils, there's a SelectorFactory which is used when NIO
> selectablechannel is used. Notice that the factory limits the total number
> of active selectors to 20, and if the pool ever runs empty, it'll wait
> maximum of 2 periods of timeout (5s) before giving up. So the blocking we
> are seeing is coming from this piece of code. (10s, 20s, 30s
> etc..)
> 
> The fix is relatively simple, since the selector (and selectionKey) is
only
> acquired in the NbChannelOutputStream when the channel is not available,
the
> code should release the selector at the finally block of the doWrite
method
> instead of waiting for the channel.close(). This will ensure that the
> limited number of selector is never kept for a long period of time.
> 
> Ex:
> } finally {
>   this.bb.clear();
>   release(this.selector, this.selectionKey); }
> 
> With this piece of code change, I was able to run the following test code
> with 100 burst request at the same time without any problem.
> 
> import java.io.BufferedReader;
> import java.io.InputStreamReader;
> 
> import org.restlet.Component;
> import org.restlet.Restlet;
> import org.restlet.data.MediaType;
> import org.restlet.data.Protocol;
> import org.restlet.data.Request;
> import org.restlet.data.Response;
> 
> public class Test2 {
> 
>   private static Component component = new Component();
> 
>   public static void main(String[] args) throws Exception {
> 
>   // Create a new Restlet component and add a HTTP server
>   // connector to it
>   component.getServers().add(Protocol.HTTP, 1234);
> 
>   // Print the requested URI path
>   StringBuffer message = new StringBuffer();
>   // setup a response with 80k
>   int size = 8;
>   char c = 'c';
>   for (int i = 0; i < size; i++) {
>   message.append(c);
>   }
>   final String s = message.toString();
>   
>   // Create a new tracing Restlet
>   Restlet restlet = new Restlet() {   
>   @Override
>   public void handle(Request request, Response
> response) {
>   response.setEntity(s, MediaType.TEXT_PLAIN);
>   }
>   };
> 
>   // Then attach it to the local host
>   component.getDefaultHost().attach("/", restlet);
> 
>   // Now, let's start the component!
>   // Note that the HTTP server connector is also automatically
>   // started.
>   component.start();
> 
>   BufferedReader in = null;
>   String line;
>   in = new BufferedReader(new InputStreamReader(System.in));
>   while (true) {
>   S

RE: Client objects are sharing connections

[webpost]

Hi Jerome.  

I have been using the net HTTP client.  I did some looking into the source 
code, and I've found that the read timeout is set in the URLConnection class.  
This means that this is not a restlet issue, but instead it's an issue with the 
URLConnection class (or more likely, I'm doing something wrong when using the 
URLConnection class).

I'm still looking into it, but it definitely is not a restlet issue.

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

RE: Random Grizzly IOException

[Jerome Louvel]

Hi Bruce,

Beautiful! I think that our Grizzly is finally going to be ready for prime
time. The fix has been applied to both SVN trunk and 1.1 branch.

Thierry is going to publish some updated benchmarks for Restlet 1.1 very
soon. Very timely!! :)

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 Bruce Lee
Envoyé : vendredi 6 mars 2009 00:22
À : discuss@restlet.tigris.org
Objet : Re: Random Grizzly IOException

Jerome Louvel  noelios.com> writes:

 >
 >
 > Hi Bruce,
 >
 > Great news!
 >
 > Regarding the 40s delay I'm puzzled... Did you monitor the state of
sockets?
 > Are they all closed in a timely manner?
 >
 > Did you try using a profiler to detect which part of the code actually  >
causes the delay?
 >
 > Best regards,
 > Jérôme Louvel
 > --
 > Restlet ~ Founder and Lead developer ~ http://www.restlet.org  > Noelios
Technologies ~ Co-founder ~ http://www.noelios.com  >

Hi Jerome,

Sorry I finally got some time to dig into this problem again and I think
I've found the cause of the round time delay in 1.1.3.

In the ByteUtils, there's a SelectorFactory which is used when NIO
selectablechannel is used. Notice that the factory limits the total number
of active selectors to 20, and if the pool ever runs empty, it'll wait
maximum of 2 periods of timeout (5s) before giving up. So the blocking we
are seeing is coming from this piece of code. (10s, 20s, 30s
etc..)

The fix is relatively simple, since the selector (and selectionKey) is only
acquired in the NbChannelOutputStream when the channel is not available, the
code should release the selector at the finally block of the doWrite method
instead of waiting for the channel.close(). This will ensure that the
limited number of selector is never kept for a long period of time.

Ex:
} finally {
this.bb.clear();
release(this.selector, this.selectionKey); }

With this piece of code change, I was able to run the following test code
with 100 burst request at the same time without any problem.

import java.io.BufferedReader;
import java.io.InputStreamReader;

import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.data.MediaType;
import org.restlet.data.Protocol;
import org.restlet.data.Request;
import org.restlet.data.Response;

public class Test2 {

private static Component component = new Component();

public static void main(String[] args) throws Exception {

// Create a new Restlet component and add a HTTP server
// connector to it
component.getServers().add(Protocol.HTTP, 1234);

// Print the requested URI path
StringBuffer message = new StringBuffer();
// setup a response with 80k
int size = 8;
char c = 'c';
for (int i = 0; i < size; i++) {
message.append(c);
}
final String s = message.toString();

// Create a new tracing Restlet
Restlet restlet = new Restlet() {   
@Override
public void handle(Request request, Response
response) {
response.setEntity(s, MediaType.TEXT_PLAIN);
}
};

// Then attach it to the local host
component.getDefaultHost().attach("/", restlet);

// Now, let's start the component!
// Note that the HTTP server connector is also automatically
// started.
component.start();

BufferedReader in = null;
String line;
in = new BufferedReader(new InputStreamReader(System.in));
while (true) {
System.out.print("> ");
System.out.flush();
line = in.readLine();
if (line.startsWith("quit") ||
line.startsWith("exit")) {
// quits the test client
break;
}
}

component.stop();
}

}

Regards,

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

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

RE: GWT Restlet Callback

[Jerome Louvel]

Hi Scooter,

Thanks for reporting those issues. 

The Callback abstract class in the GWT module is now an interface (SVN
trunk). This should have no impact in most cases as this class had a single
method. Users will just need to remove any associated @Override annotations.

 
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 : Scooter Willis [mailto:willi...@gmail.com] 
Envoyé : mardi 3 mars 2009 21:56
À : discuss@restlet.tigris.org
Objet : RE: GWT Restlet Callback

I figured out how to do this using the following and ran into another api
problem that was easy to fix with source.

I posted an earlier message about a problem I was having doing incremental
updates when developing with GWT that are a problem with innerclasses. For
some reason doing incremental code updates for a class where you are
changing code logic but not altering the class schema is a problem with
inner classes. 

When developing with GWT you want to minimize the amount of build/deploy
when you are working on code. Incremental compiles is very important for
productivity.

Basically, I want the class that is calling a REST method to be the callback
listener. A couple problems.

The first is being able to stuff a unique name in the request so that when
you get the callback to can get the name from the original calling method
and execute the appropriate callback logic. When you make multiple REST
calls in a single class sharing one callback method you need this.

I solved this by adding this to my RestHelper class
request.getAttributes().put(CALLBACK_ID, callbackID); to store a unique
string based on the calling method.

Then in the onEvent method I have String id =
(String)request.getAttributes().get(RESTHelper.CALLBACK_ID);
which allows me to handle the response with the proper code.


Then next major problem is that Callback in Rest is defined as an Abstract
class when it should be an interface. I pulled the source into my project
and changed to an interface and added another abstract class called
RestCallback that implements the interface so that you can still do inner
class version of a callback and override the onEvent method.

The only core Rest code that appears to need a Callback class to override is
HttpClientConverter.


I have solved my problem for the short term but in the event you have any
code refactoring coming up it would be nice to see Callback become an
interface or leave Callback as an abstract class that extends
CallbackInterface and change all the calling methods to use
CallbackInterface. This way it won't break code for those using the library

Thanks

Scooter Willis

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

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

RE: Integrating WADL and Spring

[Jerome Louvel]

Hi all,

This is a good idea indeed. I've made a first step by updating
WadlApplication to make it easy to customize the way resources are created
based on the WADL resource descriptor, 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é : dimanche 8 mars 2009 03:07
À : discuss@restlet.tigris.org
Objet : Re: Integrating WADL and Spring

Hi David,

On Mar 6, 2009, at 4:10 PM, David Bordoley wrote:

> On Fri, Mar 6, 2009 at 11:32 AM, Rhett Sutphin 
>  wrote:
>
>> This would be an RFE (at least, I'm not aware of any way to get it to 
>> work currently).  I'm curious about how you would tie the resources 
>> in your application context to the WADL.  Would you add a custom 
>> attribute for the spring bean id?  Is there a WADL feature which 
>> would help with this?  I'm not that familiar with it.
>>
>> Rhett
>
> Hi,
>
> The current way WADL works in Restlet is to require implementors to 
> specify the class of the resource you want to map a WADL resource to 
> using the resource's id attribute. You then pass the the WADL xml as a 
> constructor argument to a WadlComponent or WadlApplication. You can 
> see an example of this in org.restlet.test.YahooSearch.wadl (omitting 
> the details in the example below):
>
> 
>  http://api.search.yahoo.com/NewsSearchService/V1/";>
> path="newsSearch">
>
>  
> 
>
> It would be cool if you could do something similar but instead of 
> passing a Resource class (and be stuck using the default constructor 
> etc.), instead use a Spring Bean id as the resource id in WADL, and 
> have restlet use spring to wire all the resources together, thus 
> getting all the benefits of IOC, while also being able to more 
> explicitly state your resource interface in a standard method.
>
> Anyway i can open an RFE if necessary, but I wanted to ask on the list 
> first.

This is a good idea.  I think the implementation might be more generic than
just spring support, so I went ahead and entered the RFE against the WADL
component:  http://restlet.tigris.org/issues/show_bug.cgi?id=756

Thanks,
Rhett

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

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

RE: Restlet 1.1.3

[Jerome Louvel]

Hi Paul,
 
Thanks for reporting this. This is now fixed in SVN 1.1 branch and will appear 
in the upcoming Restlet 1.1.4 version (and 1.1 snapshots).
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~   
http://www.restlet.org
Noelios Technologies ~ Co-founder ~   
http://www.noelios.com

 
  _  

De : Paul Austin [mailto:paul.aus...@revolsys.com] 
Envoyé : dimanche 1 mars 2009 03:19
À : discuss@restlet.tigris.org
Objet : Re: Restlet 1.1.3


Jerome, 

It might just be the maven pom. See in bold below.

cat org.restlet.ext.spring-1.1.3.pom

   4.0.0
   org.restlet
   org.restlet.ext.spring
   1.1.3
   
  
 org.restlet
 org.restlet
 1.1.3
  
  
 org.springframework
 spring-core
 2.5
  
  
 org.springframework
 spring-context
 2.5
  
  
 org.springframework
 spring-beans
 2.5
  
  
 org.springframework
 spring-web
 2.5
  
  
 org.springframework
 spring-webmvc
 2.5
  
   

   Spring support
   Integration with Spring Framework.
   
  
 CDDL license
 http://www.opensource.org/licenses/cddl1.php
  
  
 LGPL license
 
http://www.opensource.org/licenses/lgpl-license.php
 
  
   
c

On 28-Feb-09, at 8:28 AM, Jerome Louvel wrote:


Hi Paul,

We already upgraded to Spring 2.5.6 in 1.1.2 :)

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:paul.aus...@revolsys.com] 
Envoy� : jeudi 26 f�vrier 2009 21:43
� : discuss@restlet.tigris.org
Objet : Re: Restlet 1.1.3

For the next release can you upgrade spring to 2.5.6?

Thanks,
Paul

On 26-Feb-09, at 12:31 PM, Thierry Boileau wrote:



Hello all,



Restlet 1.1.3 has been released and is available at this address 


http://www.restlet.org/downloads/.


The public maven repository has also been updated.


Javadocs, user guide, etc. are available from this address:


http://www.restlet.org/documentation/1.1/



Best regards,


Thierry Boileau



ps:


Here is the list of changes:



  - Bugs fixed


 - Fixed Regex issue in Template with fixed variables.


   Contributed by Bruno Dumon.


 - Fixed bug in ReadableRepresentation preventing channel from


   closing. Reported by Janne Husberg.


 - Fixed bug with jSSLutils integration. Reported by Dan Noble


   and fixed by Bruno Harbulot.


 - Handler is now capable of discovering allowed methods, even


   in protected Handler subclasses. Reported by Leigh Klotz.


 - Fixed the inclusion test of media types when one contains a


   "*+".


 - Fixed wrong computed "content-length" header when encoding


   representations using the Encoder. Reported by Tamas


   Cservenak.


 - Fixed wrong computed "content-location" header generated by


   the DirectoryResource. Reported by David Fogel.


 - Fixed potential bug with EncodeRepresentation when only


   Identity applies.


  - Misc


   - Upgraded JAXB to version 2.1.9.


   - Upgraded Grizzly to version 1.9.5.



--


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


=1234715



Paul Austin
President/CEO
Revolution Systems Inc.

+1 (604) 288-4304 x201
www.revolsys.com

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

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



Paul Austin
President/CEO
Revolution Systems Inc.

+1 (604) 288-4304 x201
www.revolsys.com

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

RE: POST/PUT requests take more than 2 seconds

[Jerome Louvel]

Hi Olivier,

This might be related to chunked encoding and persistent connections that
are typically used in HTTP 1.1 communications.

I've entered a defect:

"Slow responses with RESTClient"
http://restlet.tigris.org/issues/show_bug.cgi?id=757

Could you attach your sample "test.txt" file as its content and/or size
might be what triggers the issue?
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : Olivier Bruchez [mailto:oliv...@bruchez.org] 
Envoyé : mardi 3 mars 2009 15:27
À : discuss@restlet.tigris.org; Olivier Bruchez
Objet : RE: POST/PUT requests take more than 2 seconds

Hi again,

I'm working on this project again (after more than one month of
interruption).

I'm now using:

 - Restlet 1.1.3
 - curl 7.16.3
 - RESTClient 2.3
 - the same sample code as Avi (see link to his message below)

Here are the results with curl:

> time curl -X POST -d @test.txt http://localhost:3000/
Test
real0m0.008s
user0m0.003s
sys 0m0.003s

> time curl -0 -X POST -d @test.txt http://localhost:3000/
Test
real0m0.009s
user0m0.004s
sys 0m0.003s

So, no problem with curl, as previously mentioned.

Now, with RESTClient (HTTP 1.0): "Response received in 7 ms".

With RESTClient (HTTP 1.1): "Response received in 2003 ms".

That was my problem. It's perfectly reproducible. RESTClient uses HTTP 1.1
by default, which I previously hadn't realized. I don't know why curl
doesn't have the same problem, though.

At that point, I don't know if it's a bug in RESTClient or in Restlet. What
do you think?

Thanks,
Olivier

> I actually have the same problem as Avi here:
> 
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId
> =930917
> 
> Almost the same configuration, Mac OS 10.5.6. Internal HTTP server.
> 
> When handling POST/PUT requests, the Entity.getText() method takes 2
seconds to return a string.
> 
> Is there any solution to this problem, other than not using the internal
HTTP server?
> 
> Thanks,
> Olivier

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

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

RE: Client objects are sharing connections

[Jerome Louvel]

Hi Luke,

Could you tell us which Restlet client you are using? Apache HTTP client or
JDK.Net HTTP client?
 
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 : blackh...@collab.net [mailto:blackh...@collab.net] 
Envoyé : lundi 2 mars 2009 20:26
À : discuss@restlet.tigris.org
Objet : RE: Client objects are sharing connections

I found that I can turn off keep-alive by doing:

System.setProperty("http.keepAlive", "false");

It would be nice if I could reset the readTimeout timer after every
successful request though.  Then I would be able to leave keep-alive turned
on.

-Luke

> I've had an odd problem where my client connections have been prematurely
closed.  I've tracked the problem down to the Client closing the connection
due to the readTimeout expiring.  The problem is the readTimeout should not
be expiring in this case.  What I have is this:
> 
> Client client1 = new Client(...);
> client1.getContext().getParameters().add("connectTimeout", "5000"); 
> client1.getContext().getParameters().add("readTimeout", "5000"); 
> client1.handle(someRequest);
> 
> Client client2 = new Client(...);
> client2.getContext().getParameters().add("connectTimeout", "5000"); 
> client2.getContext().getParameters().add("readTimeout", "5000"); 
> client2.handle(someRequest);
> 
> Now if client1's handle() call takes 3 seconds, and client2's handle()
call takes 3 seconds, I should be Ok.  The problem is that since the two
requests are using the same connection internally, the readTimeout will
expire 2 seconds into client2's handle.
> 
> I verified that both Client objects are using the same connection.  Using
a packet packet capture, what I see is:
> 
>  - 3 way handshake for TCP connection
>  - client1 does a GET on a resource.
>  - server responds to client1's request.
>  - client2 does a PUT on a different resource.
>  - server response to client2's request.
>  - socket is closed.
> 
> Since connections can be shared internally like this, it makes the
readTimeout very dangerous to use.  This seems like a bug to me, since the
readTimeout should get reset for each handle() request.
> 
> In the meantime, is there any way I can make it so the clients don't share
the same connection?
> 
> Thanks
> -Luke

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

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

RE: JAX-RS issue with content negotiation

[Jerome Louvel]

FYI, see issue 730 for the follow-up discussion.

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 : stephan.ko...@web.de [mailto:stephan.ko...@web.de] 
Envoyé : samedi 28 février 2009 18:36
À : discuss@restlet.tigris.org
Objet : JAX-RS issue with content negotiation

Hi Fabio,

sorry that it took a long time. But now I've took a look into your web
application (http://restlet.tigris.org/issues/show_bug.cgi?id=730). I don't
understand how the providers are added to the JaxRsApplication. Do you
checked, if all MessageBodyWriters are available in the JaxRsRestlet or only
one, e.g. with the debugger?

best regards
   Stephan

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

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

RE: Problem with returning generic generic types in JAX-RS

[Jerome Louvel]

FYI, see related issue report:

"Generics unusable as return type"
http://restlet.tigris.org/issues/show_bug.cgi?id=686 
 
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 : stephan.ko...@web.de [mailto:stephan.ko...@web.de] 
Envoyé : samedi 28 février 2009 18:08
À : discuss@restlet.tigris.org
Objet : Problem with returning generic generic types in JAX-RS

Hi Jürgen,

sorry, that it takes a long time for your problem with returning generic
objects. Do you used the following?

List strings = ...
GenericEntity> entity = new
GenericEntity>(strings) {}; return Response.ok(entity).build();


directly evaluation of List generally does not work in Java. So the
GenericEntity was created in JAX-RS. There was a discussion in the JAX-RS
mailing lists about this, see
https://jsr311.dev.java.net/servlets/SearchList?list=users&searchText=Generi
cEntity&defaultField=body&Search=Search

and
https://jsr311.dev.java.net/servlets/SearchList?list=dev&searchText=GenericE
ntity&defaultField=body&Search=Search


best regards
   Stephan

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

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

RE: Re: Re: SMTP Server / Javamail

[Jerome Louvel]

FYI, there is also an existing RFE to cover this need in the future:
http://restlet.tigris.org/issues/show_bug.cgi?id=483
 
This would work in the opposite way to the current Restlet client for
JavaMail, with a similar/identical XML mail format.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  
http://www.noelios.com
 

  _  

De : Mark Derricutt [mailto:m...@talios.com] 
Envoyé : dimanche 1 mars 2009 22:08
À : discuss@restlet.tigris.org
Objet : Re: Re: Re: SMTP Server / Javamail


I've havn't spoken to Alan for awhile but I've also not seen a 1.0 release
of mailcatcher come out yet, I might ping him and see whats up with that.


On Mon, Mar 2, 2009 at 2:26 AM, Ruben Jenster 
wrote:


Hi Mark,

according to the blog of alan mailcatcher looks very promising.
Unfortunately spikesource seems to have a database problem - so there is no
access to the mailcatcher project site at the moment.
But for me that's not that bad. At least I'm not that much detracted from my
exam preparation.

Regards,
Ruben

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

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

RE: Restlet and OSGi Issues

[Jerome Louvel]

Hi all,
 
Sorry it took so long to reply. It isn't a sign of disinterest in
Restlet+OSGi at all, just lack of time due to customer engagements. If you
need timely answers, I recommend that you consider our professional support
plans:
http://www.noelios.com/products/support
 
Ok, enough commercials, let's try to address your issues:
 
1) Due to the merging of the Restlet API and Restlet engine bundles in 1.2
and to the addition of new dependencies (javax.crypto), the manifest was
broken. It did work in Restlet 1.1 last time I tested it (with Equinox).
Anyway, I've just fixed this in SVN trunk and I promise to fix all other
manifest issues reported as soon as possible (patches welcome).
 
2) Regarding connectors, we were able to reimplement our regular classpath
introspection mechanism (looking for "META-INF/services/*Helper" files).
However, due to the refactoring, the Activator wasn't declared anymore
(org.restlet.engine.internal.Activator). This is now fixed as well.
 
3) Also, I've made the "org.mortbay.jetty.ajp" imported package optional in
the "org.restlet.ext.jetty" bundle. That should solve your issue. I have
also upgraded a Jetty bundle to version 6.1.15.
 
4) There is a lack of basic documentation, so I've created a new page in the
user guide, showing a simple "Hello, world!" example as well as a more
complex one with resources and Jetty as the HTTP server:
 
"OSGi deployment"
http://wiki.restlet.org/docs_1.2/13-restlet/48-restlet/238-restlet.html
 
Note that calling "Engine.setUserClassLoader()" isn't necessary in those
cases.
 
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~  
http://www.restlet.org
Noelios Technologies ~ Co-founder ~  
http://www.noelios.com
 

  _  

De : Rob Heittman [mailto:rob.heitt...@solertium.com] 
Envoyé : vendredi 27 février 2009 15:58
À : discuss@restlet.tigris.org
Objet : Re: Restlet and OSGi Issues



Hi again David, 

Thanks again for this post! As you gave me the clue needed to temporarily
get out of a very deep hole with Jetty connector discovery in one of our
OSGi builds. Once I set
Engine.setUserClassLoader(this.getClass().getClassLoader()); in my Equinox
application, I can add the Jetty connector to the dependencies for the
application bundle, and place a
META-INF/services/org.restlet.engine.ServerHelper file in the source tree of
my application bundle to point to Jetty (or programmatically set the Engine,
but for my case it's a better temporary fix to externalize it in the file).
It doesn't make the connector especially pluggable in an OSGi way, but it
gets me out of dodge for today.

I have some ideas for improving this without breaking the core Restlet
model, but will wait for Jerome to weigh in!

- Rob

On Mon, Feb 23, 2009 at 5:40 PM, David Fogel  wrote:


3) How can we get the restlet engine to use, for example, the Jetty
connector, in the OSGI environment? We added the Jetty extension
bundle, as well as the various Jetty bundles, to our environment. But
I can't see any evidence that they're being used. the existing docs
only mention the conventional java jar-scanning technique, which
allows this to happen automatically in non-OSGi environments.

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

File upload - as stream

[Matt Rutherford]

Hi.

Is there a way to receive a file element from an html form without storing
it to disk?

I will be storing the file directly into a DB so no need to have it on disk
anywhere.

Would be nice to just stream bytes to the LargeObject.write() Postgres JDBC
method.

Sorry if this is a silly question, I'm a (enthusiastic) beginner with this
stuff. Any guidance much appreciated.

Thanks!

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