re: InterruptedException when stopping component
I'm also interested in this functionality. I had thought of starting a separate thread that does the shutdown of the component after waiting a few moments; but that seems pretty clumsy. From: Romilly Cocking romilly.cock...@gmail.com Sent: Sunday, March 15, 2009 10:11 PM To: discuss@restlet.tigris.org Subject: InterruptedException when stopping component I've implemented a ShutdownRestlet that allows clients to make a remote request to shut down its contolling Component. It works after a fashion, but an InterruptedException is thrown whenever I request a shutdown. I suspect that the ShutdownRestlet thinks it still has work to do when the Component is shut down. This must be a common requirement, but I haven't been able to find a documented solution. An example of the way this is normally done would be much appreciated. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1321846 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1332167
Re: Re: how to set default route in jax-rs
Thanks, I'll give it a try.
From: Alexander J. Perez Tchernov xas...@gmail.com
Sent: Sunday, March 15, 2009 11:03 PM
To: discuss@restlet.tigris.org
Subject: Re: Re: how to set default route in jax-rs
An simple solution might be to introduce JAX-RS resource that catch
any url addressing with help of reg-exp.
something like
@Path(value = /{resource:.*})
public class CatchAll {
public CatchAll (@PathParam(resource) String resource ) {}
}
On Sun, Mar 15, 2009 at 12:34 AM, Ty wrote:
Hi,
Thanks again for the god advice. This seems to be the call you are referring
to:
// create JAX-RS runtime environment
final JaxRsApplication application = new
JaxRsApplication(comp.getContext().createChildContext());
// set the Default restlet
application.getJaxRsRestlet().attachDefault(myDefaultRestlet);
Unfortunately this feels like I'm mixing the restlet style of API with the
jax-rs style of API. I really would prefer to keep the code a bit cleaner
than that. e.g. I have to manage the resources directly in the
myDefaultRestlet class rather than using the annotations like in my jax-rs
classes.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1323594
--
Best regards,
~ Xasima Xirohata ~
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1326594
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1332166
Re: Handling a URI fragment identifier component using jax-rs?
Thanks Simon. Another read on the RFC' and I see that I must have mis-read the first time. I was hoping to use the fragment identifier as a general way of referencing another resource. Looks like I'll have to use the query component. From: Simon Reinhardt simon.reinha...@koeln.de Sent: Sunday, March 15, 2009 11:29 PM To: discuss@restlet.tigris.org Subject: Re: Handling a URI fragment identifier component using jax-rs? Hi Ty Ty wrote: Hi, I can't seem to get a route to work for a URL that has a fragment identifier component e.g. http://site/page#fragment That's because fragment identifiers don't get sent to the server. Going by the HTTP spec there is no fragment in the request URI so the user agent has to cut it off before making the request and that's what the browsers do. You don't have any chance of getting that information over the request URI. I recommend encoding whatever you want to transfer into the query bit. Regards, Simon -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1326645 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1332160
RE: OSGi vs. Service Provider patterns
Hi Rob- I've been struggling with the same problem. In fact, I'm guessing that this Service Provider classpath/classloader hackery (made into a crazy best-practice by its inclusion in JDK 6 as the java.util.ServiceLoader) is one of the main reasons why OSGi isn't as widely adopted as it should be- OSGi is a little complicated to begin with, and you have to bundle-ize a bunch of other people's libraries, and then you get hit with these situations where some stuff looks like it just won't work at all. I also did some googling. A few people out there are trying to adapt to the Service Provider pattern for use in an OSGi context. This guy's post was discussed in a few places: http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html His strategy seems to be to use the OSGi Extender pattern, which basically means you write some code which registers a BundleListener with the container, and checks every bundle for specific resources contained within. (This type of thing is used, for instance, by Spring DM (dynamic modules), to look for bean configuration XML files in bundles from which to create Spring contexts from, and to auto-register various osgi services.) As you know, the ServiceLoader API used by a lot of java libraries involves files in META-INF/services/ where the file name is the fully-qualified name of a provider interface or base class, and the contents of the file is class names of implementations or factories. The idea in the linked article above is that his code inspects the jar file of each bundle (not the same as it's classloader, uses bundle.findEntries()) for META-INF/services/*, reads the content, and creates a lookup table (of Provider interfaces to implementation class names) in a static member of a public class. The kicker is that he then modifies the original libraries(!) to check this lookup table before doing their regular discovery process, so that the can find the implementation classes. (specifically he saves information about the original bundle which provides this metadata, and then he uses that bundle, when requested, to load the Class of the provider implementation, to be passed to the provider loader. Then instances of these classes can be created via reflection or Class.newInstance()). This is clever, but not very appealing. And it's not helpful in cases where you can't (or don't want to) create modified versions of standard tool distributions. But there's a bigger problem here. The ServiceLoader model has no lifecycle! It's based on the unchanging static classpaths used by traditionaly executed java programs. This seems fundamentally incompatible with the dynamic lifecycles supported by OSGi, for both bundles and services. Using archive metadata to passively communicate the class names of service implementations doesn't leave room for what happens when, in OSGi, the bundle goes away- the API libraries which use this pattern aren't written to ever _unload_ these implementations. The only times they work is when they happen to be written to simply re-execute the metadata search each time they're asked for an implementation, which probably shouldn't be relied on. In OSGi, the main mechanisms used for sharing functionality across bundles is exporting a package or registering a service. It seems like we should try to use these primary OSGi mechanisms before resorting to code that pilfers the archive entries of other bundles looking for metadata. The only other mechanism which is less frequently discussed is the use of bundle Fragments. (Fragments get folded into the classloader and archive entries of a parent bundle at runtime.) I think that the preferable solution in a particular situation (if a solution exists at all) depends on 1) what the relationship is between API and implementation, and 2) which code you have the ability to deploy changes to. If you have the ability to deploy changes to either/both the api and impls, then I think it's more straightforward: If the client code needs to consume potentially more than one implementation of an API, or must choose just one implementation but doesn't care which one, then the API should just be a library and not engage in service discovery at all. Impls should be registered in the OSGi service registry, and client code should use ServiceTrackers (or the like) to select one or more services. This allows for the full dynamism of OSGi. If the client code needs to consume a _specific_ single impl of an API (like choosing an XML parser implementation), then it can just import and use that implementation directly, using package dependency declarations. Another option is to package up the API and the implementation in the same bundle (and allow them to use whatever discovery mechanism they want). A variation of this might be to use bundle Fragments, where the impls become Fragments and the API is the host bundle. While they become effectively the same bundle, the fragment method allows deployment-time
Re: Is org.restlet.Client thread safe?
Yes, or at least the most recent version of it in the trunk is. But I just noticed that that version unnecessarily declares the helper field as volatile when it could be final. Jerome, Thierry -- could you enter an issue for this? I'm having trouble wrangling the issue tracker. --tim On Sun, Mar 15, 2009 at 5:16 PM, Jim Alateras j...@comware.com.au wrote: cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1328959 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1329960
Re: Set content-location header ??
You also have so set the downloadable flag Paul On 14-Mar-09, at 3:42 PM, Ty wrote: Hi, Restlet (1.2M) is refusing to set the content-location header and I can't seem to find a method that will let me set it. Does anyone know how to set the content-location header? Here's the code that I have tried: // *** Try setting the Content-Location header: restlet refuses with a log warning! *** SeriesParameter headers = new Form(); headers.add(Content-Location, request.getOriginalRef().toString()); response.getAttributes().put(org.restlet.http.headers, headers); // Set the location header: this works response.setLocationRef(locaationURI); It seems like my code is working but restlet doesn't want to let me set the content-location header. It wants me to use an API method; but I can't find one. Any suggestions? Thanks, T -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1323618 Paul Austin President/CEO Revolution Systems Inc. +1 (604) 288-4304 x201 www.revolsys.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1326815
RE: InterruptedException when stopping component
I've found a workaround; I start another thread and send stop() to the container after a 100 ms delay. It works, but it's not pretty. Is there a better solution? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1326444
Re: OSGi vs. Service Provider patterns
Thanks for that really thorough response. At this point, mentally I'm breaking the problem into two categories: 1) Libraries/projects who are receptive to OSGi compatibility and are interested in supporting OSGi. Restlet is one of these. Here we can work with/within the project to include better OSGi awareness that fits the design of the project ... I know Jerome has been working on it. Guillaume Nodet's solution might be an acceptable band-aid in these cases ... but the lifecycle issue you point out is a bigger nut to crack. 2) Libraries/projects which dont give a hang about OSGi compatibility, lifecycle, etc. I fear the JSR223 community might be one of these ... at least I don't see a useful solution emerging until at least Java 8. I suspect I'm going to be maintaining substantially different, alternate bundle-friendly versions of several such libraries for some meaningful calendar time. Might as well just step up and do it. Hopefully if these get some popularity, it will put pressure on the folks sticking with META-INF/services. - Rob On Mon, Mar 16, 2009 at 2:24 AM, David Fogel carrotsa...@gmail.com wrote: I'm not sure any of what I've written here will be helpful to you, but since we're both struggling with the same thing, I figure it'd be good to get my current thoughts on this typed up. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333092
RE: Restlet and OSGi Issues
David, Thanks, we are on the same track! I've fix the javax.xml.xpath import and a couple of others missing. But I haven't tested it outside Eclipse due to lack of time. Do you have some usage instructions for this, like which JARs should be in the classpath and which class to launch with parameters to get a clean Equinox environment outside Eclipse? Regarding the explicit dependency, it is already possible to specify the helper class in the Server/Client constructors: - Client(Context context, ListProtocol protocols, String helperClass) - Server(Context context, ListProtocol protocols, String address, int port, Restlet target, String helperClass) Otherwise, it is possible to manually register connectors with the engine: - Engine.getInstance().getRegisteredClients().add(new HttpServerHelper(null)); I've updated the wiki page. Hope this helps! 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 22:37 À : discuss@restlet.tigris.org Objet : RE: Restlet and OSGi Issues 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=4447dsMessageId=12989 72 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333105
RE: GWT Restlet Callback
Hi Scooter,
In the HttpClientConverter, we just create an anonymous inner class like
that:
// Send the request to the client
httpCall.sendRequest(request, response, new Callback() {
public void onEvent(Request request, Response response) {
updateResponse(response, httpCall);
callback.onEvent(request, response);
}
});
No need to create a separate class implementing Callback, this can be done
on the fly. Am I missing something?
Regarding the call identifier, I think that your current approach is
perfect. I'm not sure we want to hard-code anything specific in the
framework however. I've looked again at GWT's RPC callback interface and
couldn't find a similar mechanism:
com.google.gwt.user.client.rpc.AsyncCallbackT
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : webp...@tigris.org [mailto:webp...@tigris.org]
Envoyé : mardi 10 mars 2009 15:15
À : discuss@restlet.tigris.org
Objet : RE: GWT Restlet Callback
HttpClientConverter is the only code that required Callback so you will need
a new class or have it call back to itself.
It would also help in a future api change to allow for an easy way to set a
unique ID per callback so you can share listener interface among multiple
calls. This is the same way that GWT does its RPC call. Not hard to role
your own just requires a little code overhead that could be easily added in
to the core API and as part of the callback method.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13032
30
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=130
RE: Re: Restlet (Client side) + Jersey (Server side): is it possible?
Thanks a lot! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333402
RE: Grizzly NIO examples
Hi Bora, The benefit can be at two levels: 1) By leveraging NIO while handling the socket IO, Grizzly doesn't need to dedicate one thread per accepted request, therefore potentially increasing the scalability of your component. Note that the Jetty connector can also use NIO in a similar way. 2) By using direct disk to socket transfer. This is a feature of NIO that allows you to transfer content directly from the disk IO layer to the network IO layer, without having to go through the JVM memory space. This potentially allows better performance and reduced CPU load. Regarding 1), the best is to do some benchmarks to determine which connectors scales the best for your own application loads. Note that the advantage 2) doesn't work if you generate your representation dynamically. Only if you return, directly or indirectly (such as via Directory) a FileRepresentation. Now, from what you describe, it seems that you are looking for asynchronous call processing, in order to be able to release the processing thread while waiting for some external event to arrive (ec: connection to a third-party system). This isn't available yet, but there is a RFE: Support asynchronous processing http://restlet.tigris.org/issues/show_bug.cgi?id=143 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 : bora [mailto:boraozt...@hotmail.com] Envoyé : mardi 10 mars 2009 19:55 À : discuss@restlet.tigris.org; stephan.ko...@web.de Objet : Re: Grizzly NIO examples I am having a little hard time understanding the real benefit of using the Grizzly NIO with Restlet. (or the way I am suppose to use, to be more precise) Lets assume I have a Resource that does a long I/O (that talks to an external server through a socket connection) and process what returns from external server so that the Resource returns some StringRepresentation as a result. Assuming a fresh new thread is created for each Resource and for the socket connection to the external server. What would be the real benefit of switching to Grizzly I/O Server and how should this be accomplished. Should only using the Grizzly Connector improve performance since the server will handle the NIO or should I change the current code to implement some Reactor pattern? Any help is highly appreciated. Bora -- From: Stephan Koops stephan.ko...@web.de Sent: Wednesday, February 25, 2009 5:35 PM To: discuss@restlet.tigris.org Subject: Re: Grizzly NIO examples Hi Bora, normaly just put the connector in the classpath and everything is done ... best regards Stephan bora schrieb: Being also new to Grizzly, I couldn't even came across any unit tests on the usage of Grizzly NIO Connector. Is there any documentation on how to use the connector. Thanks in advance Bora -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId =1228992 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13043 78 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333423
RE: jax-rs example throwing exception: please help
Hi Ty, Note that in recent snapshots (1.1 and 1.2), there is no a lazy loading of JAX-RS providers so it won't complain about the javax/activation/DataSource missing anymore. Just be sure to include the JARs you do need in order to have the corresponding providers available to your JAX-RS application. 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é : vendredi 13 mars 2009 21:07 À : discuss@restlet.tigris.org Objet : Re: jax-rs example throwing exception: please help Hi Ty, Do you put the JAR (I think javax.activation.jar) into your classpath? best regards Stephan Ty schrieb: Hi, This is most likely a really basic problem in my configuration but I can't work it out. Any help is greatly appreciated. I have v1.2 of restlet and I'm trying to run the jax-rs example (as an application) from the org.restlet.example.jar: org.restlet.example.jaxrs I get this exception stack when I start the ExampleServer: Exception in thread main java.lang.NoClassDefFoundError: javax/activation/DataSource at org.restlet.ext.jaxrs.JaxRsRestlet.loadDefaultProviders(JaxRsRestlet.java:20 7) at org.restlet.ext.jaxrs.JaxRsRestlet.init(JaxRsRestlet.java:197) at org.restlet.ext.jaxrs.JaxRsRestlet.init(JaxRsRestlet.java:168) at org.restlet.ext.jaxrs.JaxRsApplication.init(JaxRsApplication.java:95) at org.restlet.example.jaxrs.ExampleServer.main(ExampleServer.java:57) I am using Eclipse Ganemede on OS-X 10.5 (java 1.5.0). I have included the libraries: org.restlet.jar, org.restlet.example.jar, javax.ws.rs.jar, org.restlet.ext.jaxrs_1.0.jar I must admit that I'm still quite lost as to how all the libraries fit together. Probably why I can't work out what's wrong myself. Thanks. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13184 86 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333455
RE: Is org.restlet.Client thread safe?
Hi Tim, No need for an issue for such a small change. Now checked in SVN trunk! Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com _ De : tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de Tim Peierls Envoyé : lundi 16 mars 2009 01:06 À : discuss@restlet.tigris.org Objet : Re: Is org.restlet.Client thread safe? Yes, or at least the most recent version of it in the trunk is. But I just noticed that that version unnecessarily declares the helper field as volatile when it could be final. Jerome, Thierry -- could you enter an issue for this? I'm having trouble wrangling the issue tracker. --tim On Sun, Mar 15, 2009 at 5:16 PM, Jim Alateras j...@comware.com.au wrote: cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1328 959 dsMessageId=1328959 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333468
RE: Set content-location header ??
Hi Ty, Paul is correct, you need to use the Representation#downloadable property instead. See this table for all the mappings: Mapping HTTP semantics http://wiki.restlet.org/docs_1.2/13-restlet/27-restlet/130-restlet.html 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é : dimanche 15 mars 2009 14:11 À : discuss@restlet.tigris.org Objet : Re: Set content-location header ?? You also have so set the downloadable flag Paul On 14-Mar-09, at 3:42 PM, Ty wrote: Hi, Restlet (1.2M) is refusing to set the content-location header and I can't seem to find a method that will let me set it. Does anyone know how to set the content-location header? Here's the code that I have tried: // *** Try setting the Content-Location header: restlet refuses with a log warning! *** SeriesParameter headers = new Form(); headers.add(Content-Location, request.getOriginalRef().toString()); response.getAttributes().put(org.restlet.http.headers, headers); // Set the location header: this works response.setLocationRef(locaationURI); It seems like my code is working but restlet doesn't want to let me set the content-location header. It wants me to use an API method; but I can't find one. Any suggestions? Thanks, T -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId =1323618 Paul Austin President/CEO Revolution Systems Inc. +1 (604) 288-4304 x201 www.revolsys.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13268 15 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333470
RE: Re: Restlet (Client side) + Jersey (Server side): is it possible?
Hi Guilherme, If you like the JAX-RS API, note that Restlet also have its own implementation that you can use as an alternative to Jersey. See more information here: JAX-RS extension http://wiki.restlet.org/docs_1.1/13-restlet/28-restlet/57-restlet.html 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 : Guilherme Maranhão [mailto:guilherm...@gmail.com] Envoyé : lundi 16 mars 2009 14:46 À : discuss@restlet.tigris.org Objet : RE: Re: Restlet (Client side) + Jersey (Server side): is it possible? Thanks a lot! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13334 02 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333482
RE: Broken pipes
Hi Peter, This exception is thrown when your client has closed the socket. This might be the case due to the browser timing out the connection due to lack of activity. How much time does it take you to process the request and generate your response? If this time is too long, or increases upon load, it might explain the behavior. 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 Peter Becker Envoyé : mardi 10 mars 2009 02:23 À : discuss@restlet.tigris.org Objet : Broken pipes Hello, I am getting some exceptions when testing my application -- particularly under load. The pattern looks like this (copied from stderr): === http://[]:8182/ontologyVersions/148 Mar 10, 2009 11:03:04 AM com.noelios.restlet.http.HttpServerConverter commit INFO: The connection was broken. It was probably closed by the client. java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104) at sun.nio.ch.IOUtil.write(IOUtil.java:75) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at java.nio.channels.Channels.write(Channels.java:60) at java.nio.channels.Channels.access$000(Channels.java:47) at java.nio.channels.Channels$1.write(Channels.java:134) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109) at com.noelios.restlet.http.ChunkedOutputStream.writeBuffer(ChunkedOutputStream .java:135) at com.noelios.restlet.http.ChunkedOutputStream.writeChunk(ChunkedOutputStream. java:147) at com.noelios.restlet.http.ChunkedOutputStream.write(ChunkedOutputStream.java: 123) at java.io.OutputStream.write(OutputStream.java:99) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:190) at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:111) at java.io.BufferedWriter.flush(BufferedWriter.java:235) at freemarker.core.Environment.process(Environment.java:191) at freemarker.template.Template.process(Template.java:237) at org.restlet.ext.freemarker.TemplateRepresentation.write(TemplateRepresentati on.java:347) at com.noelios.restlet.http.HttpServerCall.writeResponseBody(HttpServerCall.jav a:492) at com.noelios.restlet.http.HttpServerCall.sendResponse(HttpServerCall.java:428 ) at com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java :391) at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:148) at com.noelios.restlet.http.StreamServerHelper$ConnectionHandler.run(StreamServ erHelper.java:86) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja va:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9 07) at java.lang.Thread.run(Thread.java:619) Mar 10, 2009 11:03:04 AM com.noelios.restlet.http.StreamServerCall complete WARNING: Unable to shutdown server socket java.net.SocketException: Transport endpoint is not connected at sun.nio.ch.SocketChannelImpl.shutdown(Native Method) at sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:640) at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:360) at com.noelios.restlet.http.StreamServerCall.complete(StreamServerCall.java:102 ) at com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java :416) at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:148) at com.noelios.restlet.http.StreamServerHelper$ConnectionHandler.run(StreamServ erHelper.java:86) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja va:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9 07) at java.lang.Thread.run(Thread.java:619) === There is none
RE: InterruptedException when stopping component
Hi Romilly, Your first solution doesn't work because when you stop the component, it stops the connectors and shuts downs the active socket connections including the one serving your shutdown request. Your second solution sounds good to me. Make sure you leverage the Application#taskService to get your new thread. 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 : Romilly Cocking [mailto:romilly.cock...@gmail.com] Envoyé : dimanche 15 mars 2009 12:24 À : discuss@restlet.tigris.org Objet : RE: InterruptedException when stopping component I've found a workaround; I start another thread and send stop() to the container after a 100 ms delay. It works, but it's not pretty. Is there a better solution? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13264 44 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333512
RE: OSGi vs. Service Provider patterns
Hi guys, Just a quick reply to mention that our Restlet OSGi activator does use the META-INF/services pattern. See code here: http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet/sr c/org/restlet/engine/internal/Activator.java?view=markup Peter Kriens also suggested that we use the Whiteboard pattern, but this required a dependency on OSGi in each Restlet bundle, causing some troubles with the XDB extension that was uploading the JAR to an Oracle database JVM... See some specifications in the developers wiki: OSGi integration http://wiki.restlet.org/developers/172-restlet/124-restlet.html Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com _ De : Rob Heittman [mailto:rob.heitt...@solertium.com] Envoyé : lundi 16 mars 2009 13:37 À : discuss@restlet.tigris.org Objet : Re: OSGi vs. Service Provider patterns Thanks for that really thorough response. At this point, mentally I'm breaking the problem into two categories: 1) Libraries/projects who are receptive to OSGi compatibility and are interested in supporting OSGi. Restlet is one of these. Here we can work with/within the project to include better OSGi awareness that fits the design of the project ... I know Jerome has been working on it. Guillaume Nodet's solution might be an acceptable band-aid in these cases ... but the lifecycle issue you point out is a bigger nut to crack. 2) Libraries/projects which dont give a hang about OSGi compatibility, lifecycle, etc. I fear the JSR223 community might be one of these ... at least I don't see a useful solution emerging until at least Java 8. I suspect I'm going to be maintaining substantially different, alternate bundle-friendly versions of several such libraries for some meaningful calendar time. Might as well just step up and do it. Hopefully if these get some popularity, it will put pressure on the folks sticking with META-INF/services. - Rob On Mon, Mar 16, 2009 at 2:24 AM, David Fogel carrotsa...@gmail.com wrote: I'm not sure any of what I've written here will be helpful to you, but since we're both struggling with the same thing, I figure it'd be good to get my current thoughts on this typed up. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333636
Re: InterruptedException when stopping component
Thanks, Jerome, It's good to know I was not too far off course. What is the benefit of using the Application's getTaskService method, as opposed to creating a Thread myself and then starting my component-stopper? I'm currently just using a Component + some Restlets, and would prefer not to create an Application if I don't need to. As a bit of background, I'm planning to use the Restlet framework in getinline2, an embedded Java DSL for record-oriented processing. I've been very impressed by what I've seen so far. Regards, Romilly 2009/3/16 Jerome Louvel jerome.lou...@noelios.com Hi Romilly, Your first solution doesn't work because when you stop the component, it stops the connectors and shuts downs the active socket connections including the one serving your shutdown request. Your second solution sounds good to me. Make sure you leverage the Application#taskService to get your new thread. 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 : Romilly Cocking [mailto:romilly.cock...@gmail.com] Envoyé : dimanche 15 mars 2009 12:24 À : discuss@restlet.tigris.org Objet : RE: InterruptedException when stopping component I've found a workaround; I start another thread and send stop() to the container after a 100 ms delay. It works, but it's not pretty. Is there a better solution? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13264 44 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333512 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1333625
Re: OSGi vs. Service Provider patterns
lukewpatterson wrote: I've been searching for answers to the same questions. I commented on this blog entry: http://www.sonatype.com/people/2009/03/the-future-of-maven-osgi-join-the-tycho-users-mailing-list/ Sorry, I should have clarified that the most relevant overlapping issue from that blog comment was related to OSGi+SPI. I'll be interested to see what solution develops here. -- View this message in context: http://n2.nabble.com/OSGi-vs.-Service-Provider-patterns-tp2478338p2488348.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1335271
RE: Re: Restlet (Client side) + Jersey (Server side): is it possible?
thanks Is there a jar file that contains only the restlet-gwt classes? the files in http://www.restlet.org/downloads/ have about 15M!! Why are they so big? do they have all the engine to run restlet? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1335287
POST redirect to GET
My apologies for asking what I think should be obvious. I am using POST to upload files. Works great. When I'm done, I want to return to a standard GET URL. To do this, I am using: response.redirectTemporary(newLoc); My new location is a restlet route (of course!). It appears that the redirect is getting a POST (remember I'm inside of a POST), and not a GET. How do I redirect, setLocation, etc. so that the next URL is a GET? P.S., I tried ?method=get, but I suppose that's getting ignored because I'm not in a GET. Thanks much, Cliff Binstock -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1335863
Re: POST redirect to GET
Go back and reread the HTTP spec. In particular, read about 303 See Other on the first hit here: http://www.google.com/search?q=http+status --Erik On Mon, Mar 16, 2009 at 3:57 PM, Cliff Binstock cliff.binst...@coyotereporting.com wrote: My apologies for asking what I think should be obvious. I am using POST to upload files. Works great. When I’m done, I want to return to a standard GET URL. To do this, I am using: response.redirectTemporary(newLoc); My new location is a restlet route (of course!). It appears that the redirect is getting a POST (remember I’m inside of a POST), and not a GET. How do I redirect, setLocation, etc. so that the next URL is a GET? P.S., I tried “?method=get”, but I suppose that’s getting ignored because I’m not in a GET. Thanks much, Cliff Binstock -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1335946
RE: POST redirect to GET
Thank you! Cliff Binstock Coyote Reporting _ From: Erik Beeson [mailto:erik.bee...@gmail.com] Sent: Monday, March 16, 2009 4:09 PM To: discuss@restlet.tigris.org Subject: Re: POST redirect to GET Go back and reread the HTTP spec. In particular, read about 303 See Other on the first hit here: http://www.google.com/search?q=http+status --Erik On Mon, Mar 16, 2009 at 3:57 PM, Cliff Binstock cliff.binst...@coyotereporting.com wrote: My apologies for asking what I think should be obvious. I am using POST to upload files. Works great. When Im done, I want to return to a standard GET URL. To do this, I am using: response.redirectTemporary(newLoc); My new location is a restlet route (of course!). It appears that the redirect is getting a POST (remember Im inside of a POST), and not a GET. How do I redirect, setLocation, etc. so that the next URL is a GET? P.S., I tried ?method=get, but I suppose thats getting ignored because Im not in a GET. Thanks much, Cliff Binstock -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1336044
