)this.connection;
+ https.setHostnameVerifier(HostnameVerifier.DEFAULT);
+}
+
// These properties can only be used with Java 1.5 and upper
// releases
--Alex Milowski
On 7/27/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Alex,
Thanks for teaching me new aspects of SSL :)
We have a RFE to improve SSL support in Restlet 1.1, I've updated it to
propose the addition of a connector parameter. See details here:
http://restlet.tigris.org/issues/show_bug.cgi?id
/O/myterm
I believe the problem is in Template.java but I haven't really dug
into the code yet.
--Alex Milowski
Turning on fine logging I get the following. It looks the route
handling is correct. Is it
possible that the Reference class is doing something bad ?
Jul 17, 2007 10:49:01 AM com.noelios.restlet.component.HostRoute beforeHandle
FINE: New base URI: https://localhost:8080
Jul 17, 2007 10:49:01
*sigh*
My bug. I take the remaining part and create a new Reference() instance along
the way. That explains everything.
At least I got to dig into the code and understand it a bit better. :)
--Alex Milowski
On 7/7/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Alex,
It looks fine to me at the Restlet level... In Component, the code looks ok:
public Server add(Protocol protocol, int port) {
Server result = new Server(getContext(), protocol, null, port,
getTarget
On 7/1/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Alex,
Thanks for the detailed explanation on atomojo and for suggesting a merging
on the Atom client side. Your contribution in this area would be very
welcomed for Restlet 1.1.
The only problem is that my code relies upon my xml-infoset
or a trick
that I need to do to get this to work?
--Alex Milowski
I'm just checking in on the status of Atom integration. Has it been integrated
into the 1.1 source yet, or is it still on the todo list? Thanks.
-Alex
to this project except that it should be
easier to build now and it has an official home.
The code lets you run the embedded version of eXist and then access it
through Client
calls.
--Alex Milowski
as well.
The biggest issue in implementing the atom protocol is the storage
and retrieval of feeds. I'm using eXist to store the XML and Derby
to store relational metadata about them. That would have to be
abstracted out in a restlet-provided implementation.
--Alex Milowski
, but getting something basic running isn't so hard.
--Alex Milowski
Now that 1.0 is out, is there any word on when Atom support will be brought back
in? We'd like to be able to have a search feed, and Atom will, needless to say,
make this much easier.
() {
return getContext().getLogger();
}
public SeriesParameter getParameters() {
return getContext().getParameters();
}
};
but that seems like it might be useless if the context is shadowed somehow.
--Alex Milowski
) {
protected boolean checkSecret(String user,char [] password) {
...db lookup code...
}
};
and the guarded application is added through the setNext() method.
--Alex Milowski
setup my routing
paths without a trailing slash so that I can re-use objects that contain
routers that start with a slash?
--Alex Milowski
The way I got the bug was as follows:
String request = http://localhost:1234/;;
for(int i=0;i5*1024;i++)
request += a;
Component component = new Component();
Server server = component.getServers().add(Protocol.HTTP, 1234);
component.start();
Client client = new Client(Protocol.HTTP);
If I need to get a Slug header, I can do:
Form headers =
getRequest().getAttributes().get(org.restlet.http.headers);
String slug = headers.getValues(Slug);
but is that Slug or slug or does it not matter? For a header, it
should be case-insensitive.
--Alex Milowski
)) ...
So, what I am missing about how Reference is handled
when it is passed to a client helper?
--Alex Milowski
On 4/3/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Alex,
The remaining part property is varying depending on the routing process.
When the routing starts, this property contains the whole URI for example.
In your client helper, you should use a more stable way of extracting the
interesting
(application/xquery)) );
--Alex Milowski
If you do a GET on a URI that is too big (4k by default), the response status
will be 'null (-1)'. A quick look at the standard HTTP codes says that it
should be 'Request URI too long (414)'. Something to incorporate.
On 2/22/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Alex,
Using the latest RC4 release, you can very easily handle this case using
URI
variables. Check this tutorial section for an example on how to define URI
templates and how to get the variable values extracted via the request
attributes
What is the relationship of the Restlet project to JSR 311: JavaTM API for
RESTful Web Services ?
http://www.jcp.org/en/jsr/detail?id=311
There are some of the same people involved.
--Alex Milowski
In RC1 we indeed removed the per-application access log in favor of a shared
access log attached to the Component. This service only logs server-side
accesses to the component (via server connectors) and writes them in an
Apache-like format. The logger name used for this purpose it something
Run into a bit of an issue: It seems that if I create an Application and attach
it to a Component, the Application no longer makes use of the Component's access
logger. I'm guessing this dates back to RC1 and the deprecation of
Application's logService, but if this is the case, how do I go about
In the function detach, it calls the default route to see if it is equal to the
target that you are removing, and set the default route to null. However, if
you've never set the defaultRoute and try to detach something, you get a null
pointer error. It seems that this should be checked for.
Ok, remember when I said I had a hack to change the context logger? Well,
that's come around to bite me now. If I call
Component.getContext().getDispatcher(), by default I get a nice
TemplateDispatcher. However, because I have to create a new Context to set the
logging in, calling
Ok, so then how do I differentiate between Access log name and Context log name?
I use two different logs for the both of them in my program
Hi, I'm upgrading my codebase from beta 20 to RC4, and I've noticed that my
LogService can no longer deal with a ContextLogger (i.e.
get/setContextLoggerName have been removed). Is this true, or has the
functionality simply been moved elsewhere in a previous release?
release, that I missed)? Thanks.
-Alex
Hey Jerome,
Unfortunately, this doesn't quite make the cut. Right now what I'm trying to do
is to serve a static file with my Application. According to the tutorial,
however (http://www.restlet.org/tutorial#part06) I basically need a Component to
set up the Protocol.FILE client connector.
Update:
I've tried it with beta 23, and it seems to work as expected now. Looks like
I'll have to upgrade.
I would like to put in a feature request, though. Ideally, I would want to be
able to do something like the following:
Application app = new Application(new Context()){
public
101 - 133 of 133 matches
Mail list logo
