Grizzly on maven repo
Hello, Is there any reason why the grizzly extension is not deployed as a maven artifact ? I found that just adding a line in build.xml does the trick ! Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1271105 maven-grizzly.svndiff Description: Binary data
how to expose meta information
Hello. I want to ask if the following design is ok from the REST / ROA point of view, and if it would be easy to realize these schema in restlet (and preferable with JAX-RS ext). Let we have some resources and meta information (size, creation date, expiration date, md5, grddl) associated with each of them. Each of these resources will be accessible through regular permalink http://localhost/resource, and meta information probably will be exposed through specific headers (ETag/expire + customs lines ). I suspect that some clients (AJAX mainly) would need to access these meta information as well, but I suppose that AJAX would fail with manipulation and analyzing headers (or it will require very specific libraries). Thus I want to expose this meta information in such a way, that AJAX can fetch (or update) them using regular GET / POST / PUT methods. I have several choices to accomplish this objective. The first one is to publish meta information as sub resource like http://localhost/resource/md5, or with special convention like http://localhost/resource/!md5. The second one is to absorb media types notion and expose resources in a strange manner like http://localhost/resource.md5, http://localhost/resource.size. The third choice is to use querying like http://localhost/resource?md5, http://localhost/resource?size Actually I'm against querying, since size|md5|expiration|security data of the resource are the resource itself (although they are usually calculated, they may be explicitly changed BY the author), while querying is for non solid things. To be honest, I'm against resource.md5 schema too, but I was got an argument that if user download the meta information file (for example the GRDDL script that extracts the RDF from the original resource), he would definitely got the C:\resource.grddl file stored on his file system, instead of having C:\grddl file with no prepended resource name if we will choose the first subresource schema (resource/md5) approach. I'm really think that /# schema is good one, but I'm afraid that this complicates things. Do you have any recommendation how to design this (which approach to choose) to be compatible both with REST and AJAX clients? I know that REST claims to either publish meta info in HEADers or include them directly in resource (if it's HTML representation), but i want to allow to fetch and manipulate with meta information bypass original resource. By the way, does JAX-RS support to publish custom HEADERS or it's better to migrate to regular restlet? Actually I don't remember any examples on this. -- Best regards, ~ Xasima Xirohata ~ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1268571
JAX-RS and per methods security
Hello. Is it possible to ship an example how to operate with security in JAX-RS for the following problem. I want to specify that certain users may perform GET operation against a certain resource, and only subset of them can perform PUT /POST operation. The rest of resources don't need any authorization at all. I want to implement this common task using JAX-RS. I see that I need to create Guard to ask clients (via HTTP_DIGEST / BASIC) to provide me trust username (principals) // create a Guard final Guard guard = new Guard(application.getContext(), ChallengeScheme.HTTP_BASIC, JAX-RS example); // set valid users and thier passwords. guard.getSecrets().put(admin, adminPW.toCharArray()); I see that I need to create a RoleChecker that will perform the certain validation if the certain user (principals) belongs to certain role. 1) How can I specify that given operation against given resource is permitted only for the following ROLE 2) How can I transfer the invocation context (resource uri) to RoleChecker to let him, for example, check that given user is really in AUTHOR ROLE of the resource 3) Does this schema (with Guard / RoleChecker) work even in standalone mode, since it seems common to specify some of the parameters in web.xml / specific.xml when deploy the application. -- Best regards, ~ Xasima Xirohata ~ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1268708
Testing RESTful Web Services built with Restlet
I am looking for good ideas for testing RESTful web services built using Restlet. We have done obvious: JMeter, JUnit, and some integration testing. I'd like more automated tools that testers could use (possibly with the help of developers) that specifically address REST. The approaches I mentioned above are ad hoc in that sense. Thanks, Sean -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1267784
Re: Grizzly on maven repo
Hi Rémi, thanks for reporting this issue. The svn repository has been updated. Best regards, Thierry Boileau Hello, Is there any reason why the grizzly extension is not deployed as a maven artifact ? I found that just adding a line in build.xml does the trick ! Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1271487
RE: JSP/Servlet Representation
Hi all, The closest thing that exists right now is the XTC project integrating Restlet and Facelets: http://trac.sarugo.org/xtc Another idea would be to develop a Restlet's Request and Response wrapper for the Servlet API. Then, we could try to create a JspRepresentation and ask to an embedded JSP processor (Tomcat's Jasper?) to write it. This seems touchy but feasible. See existing RFE: Request and Response wrapper for Servlet API http://restlet.tigris.org/issues/show_bug.cgi?id=512 Also, I've entered a new RFE: Support JSP representations http://restlet.tigris.org/issues/show_bug.cgi?id=753 Anyone wants to investigate? 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é : mercredi 25 février 2009 22:34 À : discuss@restlet.tigris.org Objet : Re: JSP/Servlet Representation Hi, I also though about JSPs as response. If you use a Servlet Container as server connector (e.g. tomcat), than it should not be so hard: Just allow the return of a redirect or whatever it is called to another Servlet (here: the JSP). Of course this is a dependency to Servlet containers, but for them it is not hard, I think. best regards Stephan Rob Heittman schrieb: This is one of the biggest problems with JSP; it is very hard to use it pluggably outside of its intended JEE framework (as opposed to any of the things that work nicely with JSR223 scripting: https://scripting.dev.java.net/) ... we have run into this in our content management framework. Perversely, it's easier to craft a PHP representation than a JSP one! On a container-specific level, it is possible to instantiate and control your own instance of the container's JSP servlet (e.g. Jasper) ... but this is a hack in any universe. On Wed, Feb 25, 2009 at 12:31 PM, Dustin N. Jenkins dustin.jenk...@nrc-cnrc.gc.ca wrote: I could treat the JSP like a FreeMarker template and just replace mark-ups, but then it's not really a JSP anymore, especially for maintainers of the code after me. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12289 85 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1271904
Groovy as templating engine
Hello ! Had anyone used groovy as templating engine for creating HTML content ? I'm currently developing simple class extending WriterRepresentation to use groovy template engine. But maybe there's some external project have this functionality already implemented ? -- Regards, Evgeny Shepelyuk -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1272075
Re: Random Grizzly IOException
Jerome Louvel jerome.louvel at noelios.com writes:
Hi Bruce,
Great news!
Regarding the 40s delay I'm puzzled... Did you monitor the state of
sockets?
Are they all closed in a timely manner?
Did you try using a profiler to detect which part of the code actually
causes the delay?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Hi Jerome,
Sorry I finally got some time to dig into this problem again and I think
I've found the cause of the round time delay in 1.1.3.
In the ByteUtils, there's a SelectorFactory which is used when NIO
selectablechannel is used. Notice that the factory limits the total
number of active selectors to 20, and if the pool ever runs empty, it'll
wait maximum of 2 periods of timeout (5s) before giving up. So the
blocking we are seeing is coming from this piece of code. (10s, 20s, 30s
etc..)
The fix is relatively simple, since the selector (and selectionKey) is
only acquired in the NbChannelOutputStream when the channel is not
available, the code should release the selector at the finally block of
the doWrite method instead of waiting for the channel.close(). This will
ensure that the limited number of selector is never kept for a long
period of time.
Ex:
} finally {
this.bb.clear();
release(this.selector, this.selectionKey);
}
With this piece of code change, I was able to run the following test
code with
100 burst request at the same time without any problem.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.data.MediaType;
import org.restlet.data.Protocol;
import org.restlet.data.Request;
import org.restlet.data.Response;
public class Test2 {
private static Component component = new Component();
public static void main(String[] args) throws Exception {
// Create a new Restlet component and add a HTTP server
// connector to it
component.getServers().add(Protocol.HTTP, 1234);
// Print the requested URI path
StringBuffer message = new StringBuffer();
// setup a response with 80k
int size = 8;
char c = 'c';
for (int i = 0; i size; i++) {
message.append(c);
}
final String s = message.toString();
// Create a new tracing Restlet
Restlet restlet = new Restlet() {
@Override
public void handle(Request request, Response response) {
response.setEntity(s, MediaType.TEXT_PLAIN);
}
};
// Then attach it to the local host
component.getDefaultHost().attach(/, restlet);
// Now, let's start the component!
// Note that the HTTP server connector is also automatically
// started.
component.start();
BufferedReader in = null;
String line;
in = new BufferedReader(new InputStreamReader(System.in));
while (true) {
System.out.print( );
System.out.flush();
line = in.readLine();
if (line.startsWith(quit) || line.startsWith(exit))
{
// quits the test client
break;
}
}
component.stop();
}
}
Regards,
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1274309
Re: Random Grizzly IOException
Hi Jerome,
Sorry I finally got some time to dig into this problem again and I think
I've
found the cause of the round time delay.
In the ByteUtils, there's a SelectorFactory which is used when NIO
selectablechannel is used. Notice that the factory limits the total
number of
active selectors to 20, and if the pool ever runs empty, it'll wait
maximum of 2
periods of timeout before giving up. So the blocking we are seeing is coming
from this piece of code. (10s, 20s, 30s etc..)
The fix is relatively simple, since the selector (and selectionKey) is only
acquired in the NbChannelOutputStream when the channel is not available, the
code should release the selector at the finally block of the doWrite method
instead of waiting for the channel.close(). This will ensure that the
limited
number of selector is never kept for a long period of time.
Ex:
} finally {
this.bb.clear();
release(this.selector, this.selectionKey);
}
With this piece of code change, I was able to run the following test
code with
100 burst request at the same time without any problem.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.data.MediaType;
import org.restlet.data.Protocol;
import org.restlet.data.Request;
import org.restlet.data.Response;
public class Test2 {
private static Component component = new Component();
public static void main(String[] args) throws Exception {
// Create a new Restlet component and add a HTTP server
// connector to it
component.getServers().add(Protocol.HTTP, 1234);
// Print the requested URI path
StringBuffer message = new StringBuffer();
// setup a response with 80k
int size = 8;
char c = 'c';
for (int i = 0; i size; i++) {
message.append(c);
}
final String s = message.toString();
// Create a new tracing Restlet
Restlet restlet = new Restlet() {
@Override
public void handle(Request request, Response response) {
response.setEntity(s, MediaType.TEXT_PLAIN);
}
};
// Then attach it to the local host
component.getDefaultHost().attach(/, restlet);
// Now, let's start the component!
// Note that the HTTP server connector is also automatically
// started.
component.start();
BufferedReader in = null;
String line;
in = new BufferedReader(new InputStreamReader(System.in));
while (true) {
System.out.print( );
System.out.flush();
line = in.readLine();
if (line.startsWith(quit) || line.startsWith(exit))
{
// quits the test client
break;
}
}
component.stop();
}
}
Regards,
Jerome Louvel wrote:
Hi Bruce,
Great news!
Regarding the 40s delay I'm puzzled... Did you monitor the state of sockets?
Are they all closed in a timely manner?
Did you try using a profiler to detect which part of the code actually
causes the delay?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : news [mailto:n...@ger.gmane.org] De la part de Bruce Lee
Envoyé : jeudi 2 octobre 2008 02:42
À : discuss@restlet.tigris.org
Objet : Re: Random Grizzly IOException
Hi Jerome,
Thanks for the speedy fix yet again, all seems well (no more exceptions)
except that sometimes some request takes a long time to return. I have
yet to determine the cause though but here's the load test result using
JMeter.
Label,# Samples,Average,Median,90% Line,Min,Max,Error%,Throughput,KB/sec
Restlet Grizzly Load Test,1000,1115,5,22,4,40004,0.0,3.24859,253.796
Notice the maximum response time is 4ms (40s) but the
average/median/90% are less than 25ms. The test is done on the
previously stated system. Your dedication to this and timely response is
greatly appreciated.
Regards,
Jerome Louvel wrote:
Hi Bruce,
Thanks for the env details.
It seems to be due to a null selector passed as a parameter to the
register() method in ByteUtils. I've added an extra test in ByteUtils. It
might either fully fix the problem or move it somewhere else.
Could you test again with a recent snapshot?
http://www.restlet.org/downloads/snapshot.zip
Best regards,
Jérôme Louvel
--
Restlet ~
Restlet manifest and the Bundle Version property
Can someone tell me why the Bundle-Version property for each of the artifacts in the maven2 repository(http://maven.restlet.org/) are not correctly stating the maven version. For example, the manifest for 1.2-SNAPSHOT AND 1.2-M1 both state that the Bundle-Version is 1.2. This is not the actual version for this artifact. This causes some problems when resolving the versions of an artifact in an osgi container. Any reason why this is? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1273688
