Re: RestletServlet: [Restlet] ServerServlet couldn't find the target class
I solved the problem. The line com.adxsearch.core.server.service.rule.FirstStepsApplication was in the web.xml file. After I changed it, it worked in the new location. -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/RestletServlet-Restlet-ServerServlet-couldn-t-find-the-target-class-tp5777825p5779163.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2686060
RE: SSL Client, HttpURLConnection, 2.0-RC2, keep-alive not working
Hi Thierry!
I still want to use the HttpURLConnection in my application.
Version: 2.0.3
Module: org.restlet.ext.net
I can not make the keep-alive working.
This a big problem, since the performance is massive derading espacially using
HTTPS.
Below is my testcode. The plain HttpURLConnection is working as expected. The
restlet requests are not keept alive.
Am I doing something wrong here?
---
@Test
public void testSSL() throws Exception {
System.setProperty("javax.net.debug", "all");
for (int i = 0; i < 5; i++) {
URL url = new URL("https://www.amazon.com";);
HttpURLConnection urlConn = (HttpURLConnection)
url.openConnection();
urlConn.getContent();
urlConn.disconnect();
}
Context restletContext = new Context();
restletContext.getParameters().set("maxTotalConnections", "10");
restletContext.getParameters().set("maxConnectionsPerHost", "10");
Client client = new Client(restletContext, Protocol.HTTPS);
for (int i = 0; i < 5; i++) {
ClientResource clientResource = new
ClientResource("https://www.amazon.com";);
clientResource.setNext(client);
Representation representation = clientResource.get();
String text = representation.getText();
}
}
--
Best regards
Klaus
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2685985
Re: Child URI's
Nice write up!
But one problem I see in this is that it's a bit like IDL and the like
in SOAP and other RPC protocols. You end up having to share some kind of
interface descriptor (or load/interpret it at runtime) between the
server and the client. REST requires a well-documented URI space, as
well as well-documented representation structures, but documentation !=
IDL. A human looking up an API signature and making sure he's following
the spec makes much more sense to me than having arbitrary clients
arbitrarily talking to arbitrary servers via arbitrary protocols. :) At
best, IDL-like mechanisms provide some type safety. Although, even then,
they only provide runtime safety and can't help you during compile- or
link- time.
The bottom line is that you always need to document your URI (and API)
space well, whether you share such specs between client server or not.
Which, to me means that I'd rather not spend too much time creating spec
sharing mechanisms. I'd rather spend more time making sure my
documentation is concise, so that other programmers (or me!) will
understand the URI space in the future.
(For what it's worth, if you work a lot of dynamic languages with
dynamic and duck types, you get used to not having any compile-time
signature safety, and always rely on documentation anyway.)
Tangent: I would add that it's good practice to always think of URIs as
ending in trailing slashes. If you decide on using relative URIs, it
makes your URI space more consistent:
/user/liron/projects/
/user/liron/project/123/items/
../
(I'm also a fan of the plural vs. singular noun form URI space)
-Tal
On 11/26/2010 02:06 PM, Tim Peierls wrote:
> I'm interested in hearing other answers to this, too, but the first
> thing that occurs to me about your example is that the recipient of
> this representation would probably find an absolute URI more useful
> than a relative one. So at the very least you'd want something like this:
> String userProjects = "/user/" + user.getId() + "/projects";
> Reference userProjectsRef = new Reference(getRootRef(),
> userProjects);
> jr.put("projects", userProjectsRef.getTargetRef().toString());
>
> Furthermore, you can use a Template to regularize the construction of
> the userProjects string:
>
> // Static fields of the user resource class.
> public static final String USER_PROJECTS_PATH = "/user/{id}/projects";
> private static final Template userProjectsTemplate = new
> Template(USER_PROJECTS_PATH);
>
> When building the representation, you provide values to this template.
> Map userValues = new HashMap();
> userValues.put("id", "abc123");
> String userProjects = userProjectsTemplate.format(userValues);
> // ... as above ...
>
> And you can make this even simpler if you write a resolver for your
> user resource class.
>
> class UserResolver extends Resolver {
> UserResolver(User user) { this.user = user; }
> // Crude implementation - could do better using reflection.
> public String resolve(String name) {
> if (name.equals("id")) return user.getId();
> // ... other possibilities ...
> throw new RuntimeException("can't resolve name for user: "
> + name);
> }
> private final User user;
> }
>
> Then instead of creating a Map from the names in the template to
> string values, you can provide a resolver instance.
>
> Resolver userResolver = new UserResolver(user);
> String userProjects = userProjectsTemplate.format(userResolver);
>
> Finally, to avoid replicating the knowledge of an application's URI
> structure between the resource classes and the application class, you
> can change the routing in the application to refer to the strings used
> to construct the templates. In other words, instead of this line in
> your Application's createInboundRoot() method:
>
> router.attach("/user/{id}/projects", UserResource.class);
>
> you can say this:
>
> import static com.example.myapp.UserServerResource.USER_PROJECTS_PATH;
> ...
> router.attach(USER_PROJECTS_PATH, UserResource.class);
>
> This way if the routing changes, you only have to update the ..._PATH
> constants.
>
> Thanks for asking the question -- I learned a lot writing up my answer!
>
> --tim
>
>
> On Fri, Nov 26, 2010 at 2:14 AM, Marty La Jeunesse
> mailto:marty.lajeune...@gmail.com>> wrote:
>
> I've a User object with a name and a List of Project objects. When
> I represent with, for example, a JsonRepresentation, I do
>
>jr.put("lastName", user.getLastName());
>jr.put("projects", "user/"+user.getId()+"/projects");
>return jr;
>
> The 'projects" uri construction seems a little naive.
>
> Any suggestions?
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2685953
Re: Child URI's
I'm interested in hearing other answers to this, too, but the first thing
that occurs to me about your example is that the recipient of this
representation would probably find an absolute URI more useful than a
relative one. So at the very least you'd want something like this:
String userProjects = "/user/" + user.getId() + "/projects";
Reference userProjectsRef = new Reference(getRootRef(), userProjects);
jr.put("projects", userProjectsRef.getTargetRef().toString());
Furthermore, you can use a Template to regularize the construction of the
userProjects string:
// Static fields of the user resource class.
public static final String USER_PROJECTS_PATH = "/user/{id}/projects";
private static final Template userProjectsTemplate = new
Template(USER_PROJECTS_PATH);
When building the representation, you provide values to this template.
Map userValues = new HashMap();
userValues.put("id", "abc123");
String userProjects = userProjectsTemplate.format(userValues);
// ... as above ...
And you can make this even simpler if you write a resolver for your user
resource class.
class UserResolver extends Resolver {
UserResolver(User user) { this.user = user; }
// Crude implementation - could do better using reflection.
public String resolve(String name) {
if (name.equals("id")) return user.getId();
// ... other possibilities ...
throw new RuntimeException("can't resolve name for user: " +
name);
}
private final User user;
}
Then instead of creating a Map from the names in the template to string
values, you can provide a resolver instance.
Resolver userResolver = new UserResolver(user);
String userProjects = userProjectsTemplate.format(userResolver);
Finally, to avoid replicating the knowledge of an application's URI
structure between the resource classes and the application class, you can
change the routing in the application to refer to the strings used to
construct the templates. In other words, instead of this line in your
Application's createInboundRoot() method:
router.attach("/user/{id}/projects", UserResource.class);
you can say this:
import static com.example.myapp.UserServerResource.USER_PROJECTS_PATH;
...
router.attach(USER_PROJECTS_PATH, UserResource.class);
This way if the routing changes, you only have to update the ..._PATH
constants.
Thanks for asking the question -- I learned a lot writing up my answer!
--tim
On Fri, Nov 26, 2010 at 2:14 AM, Marty La Jeunesse <
marty.lajeune...@gmail.com> wrote:
> I've a User object with a name and a List of Project objects. When I
> represent with, for example, a JsonRepresentation, I do
>
>jr.put("lastName", user.getLastName());
>jr.put("projects", "user/"+user.getId()+"/projects");
>return jr;
>
> The 'projects" uri construction seems a little naive.
>
> Any suggestions?
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2685943
RestletServlet: [Restlet] ServerServlet couldn't find the target class
I'm trying to use the Java EE Hello World example: http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/312-restlet.html http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/312-restlet.html It worked the first time but when I rename the entry class I get the error below. I have a Java EE application. I debug it using the Eclipse plug-in Jetty Server. I use Maven and I run it from the command line using a Maven command. My problem is that when I move the working class files to another folder in my project, it still looks for the original class-files. (In this case com.adxsearch.core.server.service.rule.FirstStepsApplication) The error message is the one below. (In this case I have renamed the entrypoint-class com.adxsearch.core.server.service.rule.FirstStepsApplication2) 2010-11-26 17:06:30.430::INFO: Started selectchannelconnec...@0.0.0.0:8080 [INFO] Started Jetty Server 2010-11-26 17:06:38.095:/:WARN: RestletServlet: [Restlet] ServerServlet couldn't find the target class. Please check that your classpath includes com.adxsearch.core.server.service.rule.FirstStepsApplication java.lang.ClassNotFoundException: com.adxsearch.core.server.service.rule.FirstStepsApplication at org.restlet.engine.util.EngineClassLoader.findClass(EngineClassLoader.java:97) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.restlet.engine.Engine.loadClass(Engine.java:153) at org.restlet.ext.servlet.ServerServlet.loadClass(ServerServlet.java:950) at org.restlet.ext.servlet.ServerServlet.createApplication(ServerServlet.java:384) at org.restlet.ext.servlet.ServerServlet.getApplication(ServerServlet.java:751) at org.restlet.ext.servlet.ServerServlet.init(ServerServlet.java:904) at javax.servlet.GenericServlet.init(GenericServlet.java:241) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440) at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:112) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:915) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) 2010-nov-26 17:06:38 org.restlet.engine.log.LogFilter afterHandle INFO: 2010-11-2617:06:38127.0.0.1 - 127.0.0.1 8080GET /hello - 404 0 - 6 http://localhost:8080 Jakarta Commons-HttpClient/3.1 - 2010-nov-26 17:06:39 org.restlet.engine.log.LogFilter afterHandle INFO: 2010-11-2617:06:39127.0.0.1 - 127.0.0.1 8080GET /hello - 404 0 - 0 http://localhost:8080 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko - How do I get it to find my new class? Where is the Jetty cache in case it has been cached by Jetty on my local machine. -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/RestletServlet-Restlet-ServerServlet-couldn-t-find-the-target-class-tp5777825p5777825.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2685911
RE: Re: JAX RS + Tomcat (Servlet Container)
Hi Stephan, for now we are trying the following solution: We created an HttpServletRequestWrapper which overrides the method #getInputStream. In this method we read the parameters from request#getParameterMap and return it into an ByteArrayInputStream. We will let you know if it works. Best regards, Torsten -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2685852
RE: Redirector fails with chunked encoding
Problem solved by using (embedded) Jetty instead of the internal server at the end of the chain. There is something wrong with the handling of chunked encoding by the internal server. The effect of the Redirector and client implementation changes was to change the sizes of the chunks. Mark -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2685837
Child URI's
I've a User object with a name and a List of Project objects. When I represent
with, for example, a JsonRepresentation, I do
jr.put("lastName", user.getLastName());
jr.put("projects", "user/"+user.getId()+"/projects");
return jr;
The 'projects" uri construction seems a little naive.
Any suggestions?
Thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2685810
