Re: can't access jax-rs resource in gae
Ah. Thank you thank you. I'll try it out with the correct annotation classes! Sent from my iPhone On Oct 28, 2009, at 12:41 PM, Stephan Koops stephan.ko...@web.de wrote: Hi Michael, ok, than you accessed the resource, but no entity is available in the Response. Now I've seen that you mixed the API of JAX-RS and annotation based Restlet. For JAX-RS you shouldn't inherit from class ServerResource. And you must use the @GET from JAX-RS, not the @Get from Restlet. best regards Stephan Michael Mogley schrieb: I'm just testing locally for now (using the Google Eclipse plugin's Web-App. My URI is http://localhost:8080/rest/test/hello. In the console, I get back: Oct 28, 2009 7:01:32 PM org.restlet.engine.http.HttpServerAdapter commit WARNING: A response with an unavailable entity was returned. Ignoring the entity for resource http://localhost:8080/rest/test/hello;. On Wed, Oct 28, 2009 at 11:54 AM, Stephan Koops stephan.ko...@web.de mailto:stephan.ko...@web.de wrote: what URI do you called? best regards Stephan Michael Mogley schrieb: I've followed the example in First Steps for GAE and can't seem to access the resource from the browser. I'm running: - latest snapshot build for gae (as of 10/25/09) - AppEngine 1.2.6 - Eclipse 3.5 I've attached the relevant files. Any help greatly appreciated! Michael -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412216 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412216 -- Michael Mogley, Software Architect Wirefree Thought LLC 310-756-7074 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412234 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412237
RE: can't access jax-rs resource in gae
Hi Michael, In addition, I've also updated our documentation on Restlet edition for GAE in the wiki as it was referring to some outdated materials. For example you can leverage a simpler way to configure the ServerServlet: http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/252-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 : Michael Mogley [mailto:mrrub...@gmail.com] Envoyé : mercredi 28 octobre 2009 20:52 À : discuss@restlet.tigris.org Objet : Re: can't access jax-rs resource in gae Ah. Thank you thank you. I'll try it out with the correct annotation classes! Sent from my iPhone On Oct 28, 2009, at 12:41 PM, Stephan Koops stephan.ko...@web.de wrote: Hi Michael, ok, than you accessed the resource, but no entity is available in the Response. Now I've seen that you mixed the API of JAX-RS and annotation based Restlet. For JAX-RS you shouldn't inherit from class ServerResource. And you must use the @GET from JAX-RS, not the @Get from Restlet. best regards Stephan Michael Mogley schrieb: I'm just testing locally for now (using the Google Eclipse plugin's Web-App. My URI is http://localhost:8080/rest/test/hello. In the console, I get back: Oct 28, 2009 7:01:32 PM org.restlet.engine.http.HttpServerAdapter commit WARNING: A response with an unavailable entity was returned. Ignoring the entity for resource http://localhost:8080/rest/test/hello;. On Wed, Oct 28, 2009 at 11:54 AM, Stephan Koops stephan.ko...@web.de mailto:stephan.ko...@web.de wrote: what URI do you called? best regards Stephan Michael Mogley schrieb: I've followed the example in First Steps for GAE and can't seem to access the resource from the browser. I'm running: - latest snapshot build for gae (as of 10/25/09) - AppEngine 1.2.6 - Eclipse 3.5 I've attached the relevant files. Any help greatly appreciated! Michael -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24122 16 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412 216 -- Michael Mogley, Software Architect Wirefree Thought LLC 310-756-7074 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24122 34 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24122 37 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412481
RE: Persistent connections
Hi Rickard, The internal HTTP client doesn't support persistent connections yet. There is a plan to add support though: Support advanced HTTP connection features http://restlet.tigris.org/issues/show_bug.cgi?id=304 For now, if such feature is essential to you, I recommend leveraging our other HTTP client connectors such as the org.restlet.ext.httpclient extension based on Apache HTTP Client 4.0 (for Restlet 2.0). It has built-in support for persistent connections. 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 : Rickard Öberg [mailto:rickardob...@gmail.com] Envoyé : jeudi 29 octobre 2009 05:22 À : discuss@restlet.tigris.org Objet : Persistent connections Hi, How do I enable persistent connections using Restlet? I've checked the code, and I can't seem to find how to do it. /Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24123 83 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412493
RE: Re: RestletFrameworkServlet missing from M5 and snapshot builds
Hi Cedric, Please let us know if the Spring extension works fine on GAE and we'll include it in the Restlet edition for GAE for the next snapshot! 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 : Cedric Hurst [mailto:cedric.hu...@gmail.com] Envoyé : mercredi 28 octobre 2009 20:41 À : discuss@restlet.tigris.org Objet : RE: Re: RestletFrameworkServlet missing from M5 and snapshot builds Ah, yes. Thanks for pointing me to that post, Ben. I've swapped my ext.spring jar from the GAE with the one provided in the JEE version. I'll test it out tonight to see if the Servlet class works inside GAE. If it does, perhaps we should consider including it in the GAE distribution of Restlet? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24122 33 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412520
RE: http connection timeout and version 1.1.6
Hi Jim, When a Client instance is created, it creates and wraps an internal helper. In your case, the additional helper that you create should have no effect on the client previously created, even if you pass it in the constructor... I have just tested that it works in Restlet 2.0 (SVN trunk) and Restlet 1.1 (SVN branch). See the attached sample file. Note that it assumes you have the org.restlet.ext.net.jar (2.0) or com.noelios.restlet.ext.net.jar (1.1) in your classpath. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Jim Alateras [mailto:j...@comware.com.au] Envoyé : jeudi 29 octobre 2009 05:01 À : discuss@restlet.tigris.org Objet : Re: http connection timeout and version 1.1.6 Thanks Jerome for getting back to me. I ended doing something like this and it seems to work for me Client client = useHttps ? new Client(new Context(), Protocol.HTTPS) : new Client(new Context(), Protocol.HTTP); HttpClientHelper helper = new HttpClientHelper(client); helper.getHelpedParameters().set(readTimeout, Integer.toString(socketTimeout), false); cheers /jima On 28/10/2009, at 5:43 AM, Jerome Louvel wrote: Hi Jim, The patch you are referring to is actually attached to issue 622 but it applies to Apache HTTP Client 4.0 version now used by Restlet 2.0. It should be applied before Restlet 2.0 M6. Restlet 1.1 however is based on version 3.1 which has a different mechanism based on the IdleConnectionTimeoutThread class. Unfortunately, such a change applied to Restlet 1.1 would add a feature and not be just a bug fix... One workaround would be to develop a custom MyHttpClientHelper class extending com.noelios.restlet.ext.http.HttpClientHelper. It could then access to the httpClient property where you could set the IdleConnectionTimeoutThread. Then you would need to manually register the customized helper in the engine or use it when creating the Client instance. Hope it will help! Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com Jim Alateras a écrit : Jerome, I notice that there seems to be a patch for the http timeout connection problem some people are experiencing (http://restlet.tigris.org/issues/show_bug.cgi?id=622 ). Will this patch also be applied to the 1.1 branch? If not can you point me to the patch submitted by Sanjay. cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2409120 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2411754 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412378 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412523 Main.java Description: Binary data
Re: Building 1.1.6 with maven and ant
Here is the requested file. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412529Testsuite: org.restlet.test.RestletTestSuite Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 2.342 sec - Standard Output --- [test, status]=[1a, Not Found (404) - The server has not found anything matching the request URI] [test, status]=[1b, Not Found (404) - The server has not found anything matching the request URI] - --- - Standard Error - Oct 29, 2009 9:29:00 PM com.noelios.restlet.ext.httpclient.HttpClientHelper start INFO: Starting the HTTP client java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:546) at java.util.ArrayList.get(ArrayList.java:321) at org.restlet.test.AtomTestCase.testAtom(AtomTestCase.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768) 2009-10-29 21:29:01.939::INFO: Logging to STDERR via org.mortbay.log.StdErrLog 2009-10-29 21:29:01.943::INFO: jetty-6.1.18 2009-10-29 21:29:01.982::INFO: Started selectchannelconnec...@0.0.0.0:8182 2009-10-29 21:29:01.982::INFO: jetty-6.1.18 2009-10-29 21:29:01.986::INFO: Started selectchannelconnec...@0.0.0.0:8183 Oct 29, 2009 9:29:01 PM com.noelios.restlet.ext.httpclient.HttpClientHelper start INFO: Starting the HTTP client Oct 29, 2009 9:29:02 PM com.noelios.restlet.LogFilter afterHandle INFO: 2009-10-2921:29:02127.0.0.1 - 127.0.0.1 8182GET /efgh - 200 12 - 5 http://localhost:8182 Noelios-Restlet-Engine/1.1snapshot - Oct 29, 2009 9:29:02 PM com.noelios.restlet.LogFilter afterHandle INFO: 2009-10-2921:29:02127.0.0.1 - 127.0.0.1 8182GET /abcd - 404 330 - 0 http://localhost:8182 Noelios-Restlet-Engine/1.1snapshot - Oct 29, 2009 9:29:02 PM com.noelios.restlet.LogFilter afterHandle INFO: 2009-10-2921:29:02127.0.0.1 - 127.0.0.1 8183GET /abcd - 200 12 - 0 http://localhost:8183 Noelios-Restlet-Engine/1.1snapshot - Oct 29, 2009 9:29:02 PM com.noelios.restlet.LogFilter afterHandle INFO: 2009-10-2921:29:02127.0.0.1 - 127.0.0.1 8183GET /efgh - 404 330 - 0 http://localhost:8183 Noelios-Restlet-Engine/1.1snapshot - 2009-10-29 21:29:02.169::INFO: jetty-6.1.18 2009-10-29 21:29:02.170::INFO: Started selectchannelconnec...@0.0.0.0:8182 Oct 29, 2009 9:29:02 PM com.noelios.restlet.ext.httpclient.HttpClientHelper start INFO: Starting the HTTP client Oct 29, 2009 9:29:02 PM com.noelios.restlet.LogFilter afterHandle INFO: 2009-10-2921:29:02127.0.0.1 - 127.0.0.1 8182PUT / - 200 10 10 1 http://localhost:8182 Noelios-Restlet-Engine/1.1snapshot - Oct 29, 2009 9:29:02 PM com.noelios.restlet.local.DirectoryResource getVariants INFO: Getting variants for : file:var/folders/Ho/HoIk6gbXFJa6saaDlRxwLTI/-Tmp-/DirectoryTestCase/tests21256812142224/ Oct 29, 2009 9:29:02 PM com.noelios.restlet.local.DirectoryResource init INFO: Converted target URI: file:var/folders/Ho/HoIk6gbXFJa6saaDlRxwLTI/-Tmp-/DirectoryTestCase/tests21256812142224/ Oct 29, 2009 9:29:02 PM com.noelios.restlet.local.DirectoryResource getVariants INFO: Getting variants for : file:var/folders/Ho/HoIk6gbXFJa6saaDlRxwLTI/-Tmp-/DirectoryTestCase/tests21256812142224/ Oct 29, 2009 9:29:02 PM com.noelios.restlet.local.DirectoryResource init INFO:
Re: http connection timeout and version 1.1.6
strange that my trst cas
Hi Jim,
When a Client instance is created, it creates and wraps an internal
helper. In your case, the additional helper that you create should
have no effect on the client previously created, even if you pass it
in the constructor...
strange because i wrote a number of test cases around timeout and they
work as expected. Here is the full method
Client client = useHttps ? new Client(new Context(),
Protocol.HTTPS) :
new Client(new Context(), Protocol.HTTP);
HttpClientHelper helper = new HttpClientHelper(client);
helper.getHelpedParameters().set(readTimeout,
Integer.toString(socketTimeout), false);
try {
helper.start();
} catch (Exception exception) {
throw new RingoCoreClientException(Exception in getClient,
exception);
}
return client;
Anyway happy to convert to a sanctioned version. One more question. Is
Client thread safe? I did read somewhere that this was fixes around
march 2009. Can you pls confirm?
I have just tested that it works in Restlet 2.0 (SVN trunk) and
Restlet 1.1 (SVN branch). See the attached sample file. Note that it
assumes you have the org.restlet.ext.net.jar (2.0) or
com.noelios.restlet.ext.net.jar (1.1) in your classpath.
I did try and build it
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Jim Alateras [mailto:j...@comware.com.au]
Envoyé : jeudi 29 octobre 2009 05:01
À : discuss@restlet.tigris.org
Objet : Re: http connection timeout and version 1.1.6
Thanks Jerome for getting back to me. I ended doing something like
this and it seems to work for me
Client client = useHttps ? new Client(new Context(),
Protocol.HTTPS) :
new Client(new Context(), Protocol.HTTP);
HttpClientHelper helper = new HttpClientHelper(client);
helper.getHelpedParameters().set(readTimeout,
Integer.toString(socketTimeout), false);
cheers
/jima
On 28/10/2009, at 5:43 AM, Jerome Louvel wrote:
Hi Jim,
The patch you are referring to is actually attached to issue 622 but
it
applies to Apache HTTP Client 4.0 version now used by Restlet 2.0. It
should be applied before Restlet 2.0 M6.
Restlet 1.1 however is based on version 3.1 which has a different
mechanism based on the IdleConnectionTimeoutThread class.
Unfortunately, such a change applied to Restlet 1.1 would add a
feature
and not be just a bug fix... One workaround would be to develop a
custom
MyHttpClientHelper class extending
com.noelios.restlet.ext.http.HttpClientHelper. It could then access
to
the httpClient property where you could set the
IdleConnectionTimeoutThread. Then you would need to manually register
the customized helper in the engine or use it when creating the
Client
instance.
Hope it will help!
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Jim Alateras a écrit :
Jerome,
I notice that there seems to be a patch for the http timeout
connection problem some people are experiencing
(http://restlet.tigris.org/issues/show_bug.cgi?id=622
). Will this patch also be applied to the 1.1 branch? If not can you
point me to the patch submitted by Sanjay.
cheers
/jima
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2409120
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2411754
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412378
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412523
Main.java
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412542
ant stage-maven-2 is not working...
do i need to enable something in build.properties to get this going? cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412551
Re: ant stage-maven-2 is not working...
my bad should've looked in build.properties # Indicates if the Maven distribution should be regenerated. maven: true cheers /jima On 29/10/2009, at 10:01 PM, Jim Alateras wrote: do i need to enable something in build.properties to get this going? cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412551 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412552
Re: UrlConneciton based HTTP client tiimeouts
I have just fixed this issue in SVN 1.1 branch as well. Please try again when 1.1.7 is released or try to build locally meanwhile. apologies for the piecemeal emails but can you tell me when you reckon 1.1.7 will be available? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412558
Deploying local staged repository to remote maven repository
Gents, What do you guys use to copy the stages files generated from ant stage- maven-2 to a remote maven2 repository. cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412585
How to configure an authenticated router
Hi,
I'm trying to configure an authenticated router for a sub-path. This is not
working:
@Override
public Restlet createInboundRoot() {
Router protectedRouter = new Router(getContext());
protectedRouter.attach(/api/site, SiteResource.class); //$NON-NLS-1$
ChallengeAuthenticator authenticator = new
ChallengeAuthenticator(getContext(),
ChallengeScheme.HTTP_BASIC,
Test);
authenticator.setVerifier(new SecretVerifier() {
@Override
public boolean verify(String identifier, char[] inputSecret) {
return true;
}
});
authenticator.setNext(protectedRouter);
Router rootRouter = new Router(getContext());
rootRouter.attach(authenticator);
return rootRouter;
}
--
View this message in context:
http://n2.nabble.com/How-to-configure-an-authenticated-router-tp3912144p3912144.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412607
Dependency on gwt-servlet in the JEE edition
Is it normal that the org.restlet.jee:org.restlet depends on com.google.gwt:gwt-servlet? It seems odd. -- View this message in context: http://n2.nabble.com/Dependency-on-gwt-servlet-in-the-JEE-edition-tp3912585p3912585.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412648
RE: logging framework for restlet
Hi Arjohn, I finally found time to work on my latest suggestion. I've just checked in SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on JULI by default. There is also a new org.restlet.ext.slf4j extension which provides a Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra creation of LogRecord instances). It can be set with a system property. See updated documentation on the wiki: http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html Let me know how it works! 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 : Arjohn Kampman [mailto:arjohn.kamp...@aduna-software.com] Envoyé : lundi 19 octobre 2009 08:45 À : discuss@restlet.tigris.org Objet : Re: logging framework for restlet Hi all, Any developments or ideas wrt logging? Regards, Arjohn Arjohn Kampman wrote: Hi Jerome, Thanks for keeping an open mind to changes. Jerome Louvel wrote: [...] However, I do think it is possible to achieve something similar to SLF4JBridgeHandler, without the cost of creating the LogRecord instances. This would be possible because instead of providing a JULI Handler, we could provide a special JULI Logger for SLF4J. As we control the creation of our Restlet loggers, we don't have to catch all records of all JULI loggers like the SLF4J bridge has to do. Instead of doing Logger.getLogger(loggerName), we could do Engine.getLogger(loggerName) and this would return either a regular JULI Logger or a direct SLF4J logger wrapper. We could then provide a way in the Restlet engine to register a different logger factory. I think this option would solve the problem, at least for me. There's one other option that I thought up: restlet could switch to slf4j for logging and distribute a core jar-file (restlet-slf4j) without a specific logging implementation. Developers can that use the slf4j mechanism to pick the logging implementation of their choice. As Rhett already indicated, this means at least three jar-files will be required for running restlets. To address this concern, an additional restlet jar that includes the slf4j API as well as the slf4j-jdk14 binding could be created. Considering that slf4j has a BSD-license, I don't see any issues with that. Since this would be backwards compatible with the existing org.restlet jar, keeping that name would be a good option, IMHO. Regards, Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24026 79 -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24088 51 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412667
RE: ant stage-maven-2 is not working...
Hi Jim, No problem. Please note that for such messages, we recommend posting to the c...@restlet.tigris.org mailing list instead. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Jim Alateras [mailto:j...@comware.com.au] Envoyé : jeudi 29 octobre 2009 12:03 À : discuss@restlet.tigris.org Objet : Re: ant stage-maven-2 is not working... my bad should've looked in build.properties # Indicates if the Maven distribution should be regenerated. maven: true cheers /jima On 29/10/2009, at 10:01 PM, Jim Alateras wrote: do i need to enable something in build.properties to get this going? cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24125 51 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24125 52 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412672
RE: UrlConneciton based HTTP client tiimeouts
Jim, We plan to release 1.1.7 next month with 2.0 M6, unless an urgent security issue appears. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Jim Alateras [mailto:j...@comware.com.au] Envoyé : jeudi 29 octobre 2009 12:16 À : discuss@restlet.tigris.org Objet : Re: UrlConneciton based HTTP client tiimeouts I have just fixed this issue in SVN 1.1 branch as well. Please try again when 1.1.7 is released or try to build locally meanwhile. apologies for the piecemeal emails but can you tell me when you reckon 1.1.7 will be available? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24125 58 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412674
RE: http connection timeout and version 1.1.6
Jim,
This is weird indeed, maybe I miss something but client doesn't have a link
to your helper variable, despite the fact that you pass client to the
constructor of HttpClientHelper. So, the helper is properly configured but the
client wouldn't leverage it.
Client was designed to be thread safe. Only ClientResource was not designed for
concurrent access by several threads.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Jim Alateras [mailto:j...@comware.com.au]
Envoyé : jeudi 29 octobre 2009 11:45
À : discuss@restlet.tigris.org
Objet : Re: http connection timeout and version 1.1.6
strange that my trst cas
Hi Jim,
When a Client instance is created, it creates and wraps an internal
helper. In your case, the additional helper that you create should
have no effect on the client previously created, even if you pass it
in the constructor...
strange because i wrote a number of test cases around timeout and they
work as expected. Here is the full method
Client client = useHttps ? new Client(new Context(),
Protocol.HTTPS) :
new Client(new Context(), Protocol.HTTP);
HttpClientHelper helper = new HttpClientHelper(client);
helper.getHelpedParameters().set(readTimeout,
Integer.toString(socketTimeout), false);
try {
helper.start();
} catch (Exception exception) {
throw new RingoCoreClientException(Exception in getClient,
exception);
}
return client;
Anyway happy to convert to a sanctioned version. One more question. Is
Client thread safe? I did read somewhere that this was fixes around
march 2009. Can you pls confirm?
I have just tested that it works in Restlet 2.0 (SVN trunk) and
Restlet 1.1 (SVN branch). See the attached sample file. Note that it
assumes you have the org.restlet.ext.net.jar (2.0) or
com.noelios.restlet.ext.net.jar (1.1) in your classpath.
I did try and build it
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Jim Alateras [mailto:j...@comware.com.au]
Envoyé : jeudi 29 octobre 2009 05:01
À : discuss@restlet.tigris.org
Objet : Re: http connection timeout and version 1.1.6
Thanks Jerome for getting back to me. I ended doing something like
this and it seems to work for me
Client client = useHttps ? new Client(new Context(),
Protocol.HTTPS) :
new Client(new Context(), Protocol.HTTP);
HttpClientHelper helper = new HttpClientHelper(client);
helper.getHelpedParameters().set(readTimeout,
Integer.toString(socketTimeout), false);
cheers
/jima
On 28/10/2009, at 5:43 AM, Jerome Louvel wrote:
Hi Jim,
The patch you are referring to is actually attached to issue 622 but
it
applies to Apache HTTP Client 4.0 version now used by Restlet 2.0. It
should be applied before Restlet 2.0 M6.
Restlet 1.1 however is based on version 3.1 which has a different
mechanism based on the IdleConnectionTimeoutThread class.
Unfortunately, such a change applied to Restlet 1.1 would add a
feature
and not be just a bug fix... One workaround would be to develop a
custom
MyHttpClientHelper class extending
com.noelios.restlet.ext.http.HttpClientHelper. It could then access
to
the httpClient property where you could set the
IdleConnectionTimeoutThread. Then you would need to manually register
the customized helper in the engine or use it when creating the
Client
instance.
Hope it will help!
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Jim Alateras a écrit :
Jerome,
I notice that there seems to be a patch for the http timeout
connection problem some people are experiencing
(http://restlet.tigris.org/issues/show_bug.cgi?id=622
). Will this patch also be applied to the 1.1 branch? If not can you
point me to the patch submitted by Sanjay.
cheers
/jima
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2409120
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2411754
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412378
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412523
Main.java
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412542
RE: Deploying local staged repository to remote maven repository
Jim, The copy is done locally on our build machine which happens to be our Web server as well :) Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Jim Alateras [mailto:j...@comware.com.au] Envoyé : jeudi 29 octobre 2009 13:01 À : discuss@restlet.tigris.org Objet : Deploying local staged repository to remote maven repository Gents, What do you guys use to copy the stages files generated from ant stage- maven-2 to a remote maven2 repository. cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24125 85 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412679
Re: restlet 1.1.6 with equinox ?!
Hi Jerome, thanks for the reply. I finally got restlet 1.1.6 running in Equinox: Instead of placing restlet in the bundle of my project (seems to be a typical osgi-newbie failure), I registered it as a seperate bundle. Besides having restlet running I now have a clean OSGi setup. Regards Moritz On Tue, Oct 27, 2009 at 13:36, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Moritz, The wiki page refers to Restlet version 1.2 which is now Restlet 2.0. Those packages don't exist in Restlet 1.1. In your case, you see to be missing the com.noelios.restlet package and probably some subpackges which contain the Restlet engine, implementing the Restlet API. Let us know if it works better. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com Moritz Maisel a écrit : Hi, I tried to build a setup of restlet 1.1.6 with equinox as described in: http://wiki.restlet.org/docs_1.2/13-restlet/48-restlet/238-restlet.html I'm running eclipse 3.5 instead of 3.4 as used in the tutorial, are there any known issues with that? Step 6 of the tutorials first part is In the Dependencies tab of the manifest editor, import the following packages: org.restlet, org.restlet.data, org.restlet.representation, org.restlet.resource, org.restlet.security, org.restlet.service, org.restlet.util. My problem is, that org.restlet.representation and org.restlet.security seem to be missing in restlet 1.1.6, at least I get an error when adding them to the Import-Package list. In a naive attempt I just ignored that and tried without them, but I end up with the following output on the osgi console: /osgi 16.10.2009 18:57:14 org.restlet.util.Engine getInstance/ /SCHWERWIEGEND: Unable to find an implementation of the Restlet API. Please check your classpath./ /16.10.2009 18:57:14 org.restlet.Restlet init/ /SCHWERWIEGEND: Unable to fully initialize the Restlet. No Restlet engine available./ My MANIFEST.MF looks like this: /Manifest-Version: 1.0/ /Bundle-ManifestVersion: 2/ /Bundle-Name: FooBarService/ /Bundle-SymbolicName: foo.bar/ /Bundle-Version: 1.0.0.qualifier/ /Bundle-Activator: foo.bar.Activator/ /Import-Package: org.osgi.framework;version=1.3.0,/ / org.restlet,/ / org.restlet.data,/ / org.restlet.resource,/ / org.restlet.service,/ / org.restlet.util/ /Bundle-RequiredExecutionEnvironment: JavaSE-1.6/ Does anyone of you have an idea what I am doing wrong? Some hint to a combination of restlet - equinox - eclipse versions that are known to work would also be great. I would like to stick with restlet, so it's ok for me to switch from equinox to apache felix if there are any problems with equinox. Kind regards Moritz -- sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de http://www.sipgate.de - www.sipgate.at http://www.sipgate.at - www.sipgate.co.uk http://www.sipgate.co.uk -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2411659 -- sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.at - www.sipgate.co.uk -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412694
Re: Null Context in ServerResource through SpringBeanFinder
Hi Jerome,
I sent a tar file containing the source and WAR file, but the attachment
was 4.4M in the end. It sent fine, but I haven't seen it pop up on
here. Is there a better way to get it to you? Or will it come through
eventually?
Thanks,
Dustin
Jerome Louvel wrote:
Hi Dustin,
Thanks for all the details. Would it be possible for you to send a mini
project (Eclipse or other) that would reproduce the issue? That would
really help us resolving any issue quickly.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Dustin N. Jenkins a écrit :
I should mention too that I have my component defined:
!-- The Restlet Component --
bean name=component class=org.restlet.ext.spring.SpringComponent
property name=defaultTarget ref=application /
property name=context ref=component.context /
property name=clientsList
list
valuehttp/value
valuefile/value
/list
/property
/bean
bean name=component.context
class=org.springframework.beans.factory.config.PropertyPathFactoryBean /
And also in my web.xml:
context-param
param-nameorg.restlet.component/param-name
param-valuecomponent/param-value
/context-param
Thanks!
Dustin
Dustin N. Jenkins wrote:
Hello!
I'm using Java 1.6, Tomcat 6, RESTlet 2.0M5, Spring 2.5, the supported
version of FreeMarker, all on Linux.
The relevant part of my spring configuration looks like this:
bean id=freeMarkerConfig
class=org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer
...
/bean
bean id=application name=application class=org.restlet.Application
property name=root ref=router /
...
/bean
bean name=router class=org.restlet.ext.spring.SpringBeanRouter /
bean abstract=true name=baseResource scope=prototype
class=ca.nrc.cadc.dp.web.restlet.resources.AbstractResource
!-- Method to configure FreeMarker using the FreeMarker Configurer. --
property name=freeMarkerConfigViaConfigurer
ref=freeMarkerConfigurer /
/bean
Which is very straightforward and worked fine with the 1.1.x versions of
RESTlet. Here are the relevant parts of my web.xml also:
context-param
param-nameorg.restlet.application/param-name
param-valueapplication/param-value
/context-param
servlet
servlet-nameRestletServer/servlet-name
servlet-classorg.restlet.ext.spring.SpringServerServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameRestletServer/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
My problem is that in my baseResource bean, I create a new
ContextTemplateLoader for FreeMarker to use, and I pass it getContext()
like so:
/**
* Set the FreeMarker Configuration.
*
* @param freeMarkerConfig The FreeMarker Configuration instance.
*/
public void setFreeMarkerConfig(final Configuration freeMarkerConfig)
{
if (freeMarkerConfig == null)
{
throw new FreeMarkerConfigurationException(
FreeMarker Configuration cannot be NULL);
}
this.freeMarkerConfig = freeMarkerConfig;
freeMarkerConfig.setTemplateLoader(
new ContextTemplateLoader(getContext(),
war:///freemarker-templates/));
}
public void setFreeMarkerConfigViaConfigurer(
final FreeMarkerConfigurer springFreeMarkerConfigurer)
{
setFreeMarkerConfig(springFreeMarkerConfigurer.getConfiguration());
}
but getContext() returns null because the ServerResource's context
member is null. Is there a step I need to set the Context? The
SpringBeanFinder from the Router is passing in a null Context when the
init(Context, Request, Response) method is called on the
ServerResource. Has anyone else experienced this? I have not tried the
SVN trunk of RESTlet yet.
Many thanks!
Dustin
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2411727
--
Dustin N. Jenkins | Tel/Tél: 250.363.3101 | dustin.jenk...@nrc-cnrc.gc.ca
facsimile/télécopieur: (250) 363-0045
National Research Council Canada | 5071 West Saanich Rd, Victoria BC.
V9E 2E7
Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria
(C.-B) V9E 2E7
Government of Canada | Gouvernement du Canada
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412718
Re: How to configure an authenticated router
I found the solution... we simply have to return the authenticator.
Router router = new Router(getContext());
router.attach(/api/site, SiteResource.class); //$NON-NLS-1$
ChallengeAuthenticator authenticator = new
ChallengeAuthenticator(getContext(),
ChallengeScheme.HTTP_BASIC,
Test);
authenticator.setVerifier(new SecretVerifier() {
@Override
public boolean verify(String identifier, char[] secret) {
return true;
}
});
authenticator.setNext(router);
return authenticator;
legege wrote:
Hi,
I'm trying to configure an authenticated router for a sub-path. This is
not working:
@Override
public Restlet createInboundRoot() {
Router protectedRouter = new Router(getContext());
protectedRouter.attach(/api/site, SiteResource.class); //$NON-NLS-1$
ChallengeAuthenticator authenticator = new
ChallengeAuthenticator(getContext(),
ChallengeScheme.HTTP_BASIC,
Test);
authenticator.setVerifier(new SecretVerifier() {
@Override
public boolean verify(String identifier, char[] inputSecret) {
return true;
}
});
authenticator.setNext(protectedRouter);
Router rootRouter = new Router(getContext());
rootRouter.attach(authenticator);
return rootRouter;
}
--
View this message in context:
http://n2.nabble.com/How-to-configure-an-authenticated-router-tp3912144p3914350.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412744
Enforcing HTTP accept header
Hi, Is there a way to enforce the HTTP Accept header? Thanks -- View this message in context: http://n2.nabble.com/Enforcing-HTTP-accept-header-tp3914375p3914375.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412749
Xstream naming convension
I would suggest to rename XstreamRepresentation to XStreamRepresentation (capital S), to follow the naming of the XStream library itself. This would also affect the setXstream() method, which should become setXStream(). What's your thought? Thanks -- View this message in context: http://n2.nabble.com/Xstream-naming-convension-tp3914466p3914466.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412755
Re: Enforcing HTTP accept header
As in, enforce a particular value in it? Check here: http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/130-restlet.html which shows us we can get the value from the header by querying the ClientInfo object like this: request.getClientInfo().getAcceptedMediaTypes() Which will return a list of the media types that were sent in that header. What you do with that info is pretty application specific. Perhaps a Filter that verifies the value in the beforeHandle method and takes some action if the values are not favorable? That would be a way to enforce it on every request. You could also verify it per resource or some other solution. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412760
SEVERE: don't pass the component context to child Restlets anymore
Gents, I am using the latest on 1.1 branch and am getting a whole lot of SEVERE errors. while running my test cases but they seem to be benign. SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Finder Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Route Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Finder Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Route Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412787
Re: Null Context in ServerResource through SpringBeanFinder
From some further investigation, it looks like the problem stems from
the Finder class still using the deprecated methods, which require the
Resource class instead of the ServerResource class. Fixing this may be
as simple as overriding the findTarget() method to return the result of
the find() method.
Dustin
Dustin N. Jenkins wrote:
Hi Jerome,
I sent a tar file containing the source and WAR file, but the attachment
was 4.4M in the end. It sent fine, but I haven't seen it pop up on
here. Is there a better way to get it to you? Or will it come through
eventually?
Thanks,
Dustin
Jerome Louvel wrote:
Hi Dustin,
Thanks for all the details. Would it be possible for you to send a mini
project (Eclipse or other) that would reproduce the issue? That would
really help us resolving any issue quickly.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Dustin N. Jenkins a écrit :
I should mention too that I have my component defined:
!-- The Restlet Component --
bean name=component class=org.restlet.ext.spring.SpringComponent
property name=defaultTarget ref=application /
property name=context ref=component.context /
property name=clientsList
list
valuehttp/value
valuefile/value
/list
/property
/bean
bean name=component.context
class=org.springframework.beans.factory.config.PropertyPathFactoryBean /
And also in my web.xml:
context-param
param-nameorg.restlet.component/param-name
param-valuecomponent/param-value
/context-param
Thanks!
Dustin
Dustin N. Jenkins wrote:
Hello!
I'm using Java 1.6, Tomcat 6, RESTlet 2.0M5, Spring 2.5, the supported
version of FreeMarker, all on Linux.
The relevant part of my spring configuration looks like this:
bean id=freeMarkerConfig
class=org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer
...
/bean
bean id=application name=application class=org.restlet.Application
property name=root ref=router /
...
/bean
bean name=router class=org.restlet.ext.spring.SpringBeanRouter /
bean abstract=true name=baseResource scope=prototype
class=ca.nrc.cadc.dp.web.restlet.resources.AbstractResource
!-- Method to configure FreeMarker using the FreeMarker Configurer. --
property name=freeMarkerConfigViaConfigurer
ref=freeMarkerConfigurer /
/bean
Which is very straightforward and worked fine with the 1.1.x versions of
RESTlet. Here are the relevant parts of my web.xml also:
context-param
param-nameorg.restlet.application/param-name
param-valueapplication/param-value
/context-param
servlet
servlet-nameRestletServer/servlet-name
servlet-classorg.restlet.ext.spring.SpringServerServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameRestletServer/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
My problem is that in my baseResource bean, I create a new
ContextTemplateLoader for FreeMarker to use, and I pass it getContext()
like so:
/**
* Set the FreeMarker Configuration.
*
* @param freeMarkerConfig The FreeMarker Configuration instance.
*/
public void setFreeMarkerConfig(final Configuration freeMarkerConfig)
{
if (freeMarkerConfig == null)
{
throw new FreeMarkerConfigurationException(
FreeMarker Configuration cannot be NULL);
}
this.freeMarkerConfig = freeMarkerConfig;
freeMarkerConfig.setTemplateLoader(
new ContextTemplateLoader(getContext(),
war:///freemarker-templates/));
}
public void setFreeMarkerConfigViaConfigurer(
final FreeMarkerConfigurer springFreeMarkerConfigurer)
{
setFreeMarkerConfig(springFreeMarkerConfigurer.getConfiguration());
}
but getContext() returns null because the ServerResource's context
member is null. Is there a step I need to set the Context? The
SpringBeanFinder from the Router is passing in a null Context when the
init(Context, Request, Response) method is called on the
ServerResource. Has anyone else experienced this? I have not tried the
SVN trunk of RESTlet yet.
Many thanks!
Dustin
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2411727
--
Dustin N. Jenkins | Tel/Tél: 250.363.3101 | dustin.jenk...@nrc-cnrc.gc.ca
facsimile/télécopieur: (250) 363-0045
National Research Council Canada | 5071 West Saanich Rd, Victoria BC.
V9E 2E7
Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria
(C.-B) V9E 2E7
Government of Canada | Gouvernement du Canada
Re: SEVERE: don't pass the component context to child Restlets anymore
Hi Jim, It's actually quite important to separate the various settings you pass to the Component (and the connectors) from those you pass to the Application itself. This way, you prevent leakage of sensitive information (such as private keys for SSL connectors) to the Application. One easy way to solve this is to set the Application's context to component.getContext().createChildContext(), either in the Application constructor or via setContext(). Best wishes, Bruno. Jim Alateras wrote: Gents, I am using the latest on 1.1 branch and am getting a whole lot of SEVERE errors. while running my test cases but they seem to be benign. SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Finder Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Route Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Finder Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Route Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412787 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412844
custom authentication ??
Hi, I am trying to implement my own authentication (and then authorisation) in restlet; but I am having some trouble. Hopefully someone can give me a hand; the doco seems somewhat out of date with respect to jax-rs. I have a jax-rs restlet server that will receive a HTTP message that includes the final part of the HTTP_NTLM challenge/response process: type3 NTLM content inside the autheticate header. I want my restlet to decode the type3 NTLM (I already have this code) and pull out the userId, domainName and workstationId and check them against the content of the URI and my own database. If they all match then the request should be processed. The client code I have is: ClientResource resource= new ClientResource(serverAddress); ChallengeResponse challenge = new ChallengeResponse(ChallengeScheme.HTTP_NTLM, ntlmType3Data); resource.setChallengeResponse(challenge); Representation representation = resource.get(); The server code I have is: component = new Component(); component.getServers().add(protocol, ipAddress, port); JaxRsApplication application = new JaxRsApplication(component.getContext().createChildContext()); application.add(new MyApplication()); final MyAuthenticator guardMyApplication = new MyAuthenticator(application.getContext(), false, ChallengeScheme.HTTP_NTLM, MyApp); MyVerifier verifier = new MyVerifier(); guardMyApplication.setVerifier(verifier); application.setGuard(guardMyApplication); component.getDefaultHost().attach(application); The MyAuthenticator class extends ChallengeAuthenticator and has no custom code in it. The MyVerifier class extends Verifier and has an implementation for the verify() method. This is what I do in my verify() method: ChallengeResponse cRes = request.getChallengeResponse(); String credentials = cRes.getCredentials(); String identifier = cRes.getIdentifier(); I get an exception when getCredentials() is called. This is a dead end for me because I need the data from the authorization header to do the verification. I also get an warning message saying that restlet does not support HTTP_NTLM: Challenge scheme HTTP_NTLM not supported by the Restlet engine. I assume I havn't got this hooked together properly. Can someone please help. Thanks, Ty -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412883
Re: logging framework for restlet
Small mistake in the wiki: It says: org.restlet.engine.loggerFacadeClass=org.restlet.ext.slf4j.Slf4jLogFacade But it should be: org.restlet.engine.loggerFacadeClass=org.restlet.ext.slf4j.Slf4jLoggerFacade Jerome, this is a small but very considerate addition to Restlet. It's always good to see how you listen to what users want. Thanks! -Tal On 10/29/2009 09:36 AM, Jerome Louvel wrote: Hi Arjohn, I finally found time to work on my latest suggestion. I've just checked in SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on JULI by default. There is also a new org.restlet.ext.slf4j extension which provides a Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra creation of LogRecord instances). It can be set with a system property. See updated documentation on the wiki: http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html Let me know how it works! 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 : Arjohn Kampman [mailto:arjohn.kamp...@aduna-software.com] Envoyé : lundi 19 octobre 2009 08:45 À : discuss@restlet.tigris.org Objet : Re: logging framework for restlet Hi all, Any developments or ideas wrt logging? Regards, Arjohn Arjohn Kampman wrote: Hi Jerome, Thanks for keeping an open mind to changes. Jerome Louvel wrote: [...] However, I do think it is possible to achieve something similar to SLF4JBridgeHandler, without the cost of creating the LogRecord instances. This would be possible because instead of providing a JULI Handler, we could provide a special JULI Logger for SLF4J. As we control the creation of our Restlet loggers, we don't have to catch all records of all JULI loggers like the SLF4J bridge has to do. Instead of doing Logger.getLogger(loggerName), we could do Engine.getLogger(loggerName) and this would return either a regular JULI Logger or a direct SLF4J logger wrapper. We could then provide a way in the Restlet engine to register a different logger factory. I think this option would solve the problem, at least for me. There's one other option that I thought up: restlet could switch to slf4j for logging and distribute a core jar-file (restlet-slf4j) without a specific logging implementation. Developers can that use the slf4j mechanism to pick the logging implementation of their choice. As Rhett already indicated, this means at least three jar-files will be required for running restlets. To address this concern, an additional restlet jar that includes the slf4j API as well as the slf4j-jdk14 binding could be created. Considering that slf4j has a BSD-license, I don't see any issues with that. Since this would be backwards compatible with the existing org.restlet jar, keeping that name would be a good option, IMHO. Regards, Arjohn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=24026 79 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412891
RE: Re: RestletFrameworkServlet missing from M5 and snapshot builds
This seems to run fine in my local environment, but when I attempt to run directly on the app engine and access a URI mapped to my RestletFrameworkServlet, I get the following error... avax.servlet.ServletException: java.lang.SecurityException: Google App Engine does not support subclasses of java.util.logging.Logger: org/restlet/ext/servlet/internal/ServletLogger at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:437) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:256) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:612) at org.mortbay.jetty.servlet.Context.startContext(Context.java:139) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:191) at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:168) at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:127) at com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:239) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:5135) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:5133) at com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24) at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:363) at com.google.net.rpc.impl.Server$2.run(Server.java:814) at com.google.tracing.LocalTraceSpanRunnable.run(LocalTraceSpanRunnable.java:56) at com.google.tracing.LocalTraceSpanBuilder.internalContinueSpan(LocalTraceSpanBuilder.java:516) at com.google.net.rpc.impl.Server.startRpc(Server.java:769) at com.google.net.rpc.impl.Server.processRequest(Server.java:351) at com.google.net.rpc.impl.ServerConnection.messageReceived(ServerConnection.java:437) at com.google.net.rpc.impl.RpcConnection.parseMessages(RpcConnection.java:319) at com.google.net.rpc.impl.RpcConnection.dataReceived(RpcConnection.java:290) at com.google.net.async.Connection.handleReadEvent(Connection.java:436) at com.google.net.async.EventDispatcher.processNetworkEvents(EventDispatcher.java:762) at com.google.net.async.EventDispatcher.internalLoop(EventDispatcher.java:207) at com.google.net.async.EventDispatcher.loop(EventDispatcher.java:101) at com.google.net.rpc.RpcService.runUntilServerShutdown(RpcService.java:251) at com.google.apphosting.runtime.JavaRuntime$RpcRunnable.run(JavaRuntime.java:396) at java.lang.Thread.run(Unknown Source) -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412907
