Please help me test it! Especially exciting is support for HTTP/2.
Available here:
https://github.com/tliron/restlet-jetty9
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3128986
After many dev releases, I'm happy to announce the betas for two new products
of interest to Restlet users.
Both of these products require JVM 6+, but also make use of the new Nashorn
engine when run on JVM 8.
SINCERITY
This is a package/bootstrapping manager for the JVM. It comes with
Great! I agree with this new direction.
Well, for now I will implement your requested feature.
Hi Tal,
In RF 3.0, we should really give more precise control regarding extensions
--
Actually, it's a feature I would like to see with *all* Restlet extensions: it
would be nice for users to be able select which extensions they want to use,
rather than configure it solely via the classpath.
Possibly with Java properties? I can imagine every extension class having an
enabled
I went ahead and also added a Jetty 9 client connector:
https://github.com/tliron/restlet-jetty9
Note that if you add the Jar to your classpath, both the server and client
connectors will be activated.
--
Binaries and API documentation are now available via the GitHub project site.
Enjoy!
https://github.com/tliron/restlet-jetty9
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3068157
Excellent. If anyone has comments, here is the GitHub issue:
https://github.com/restlet/restlet-framework-java/issues/793
That's fine Tal, whatever works best for you. Merging by hand won't be a
big issue anyway.
You might want to enter an issue in RF repo to let people discover this
So, I went ahead and created a Jetty 9 extension for Restlet 2.2:
https://github.com/tliron/restlet-jetty9
It's not much tested (especially SSL), but it does work! There are also 2
helper parameters that I still haven't found how to duplicate on Jetty 9, so
they are just be ignored. Actually,
Thanks, Jerome.
I picked the Apache License 2.0, and am hosting it as a separate project. I'm
assigning joint copyright on it to Restlet S.A.S, per the contributor
agreement, so you are free to merge it should you ever wish to do so:
https://github.com/tliron/restlet-jetty9
Rather than a
Can Restlet 2.2 work use Jetty 9 as its connector?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3067974
The answer, unfortunately, is no: Restlet uses AJP to connect to Jetty, which
is unfortunate because it's not a recommended protocol, and has been dropped in
Jetty 9.
Would it be possible to change the Jetty connector so that it would work with
either Jetty 8 or 9? It's very unfortunate that
.
Jerome
2013/11/6 Bryan Hunt bhunt at mac dot com
You can always use the servlet extension with Jetty.
Bryan
On Nov 06, 2013, at 08:45 AM, Tal Liron tal dot liron at threecrickets dot
com
wrote:
The answer, unfortunately, is no: Restlet uses AJP to connect to Jetty
Any idea or plan on when 2.2 will be released?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3066202
I use virtual hosts a lot, but I almost always use setResourcePort so
that applications can work on different ports. I'm wondering:
1) What is setServerPort for?
2) What is setHostPort for?
Setting either of these seems to make no different in routing incoming
requests.
The JavaDocs for
The DEFLATE issues:
https://github.com/restlet/restlet-framework-java/issues/653
https://github.com/restlet/restlet-framework-java/issues/654
The decoding/encoding issue is trickier, and may require some discussion:
https://github.com/restlet/restlet-framework-java/issues/655
I'm copy-pasting
OK, I now understand what is causing these exception and would like to suggest
a solution in Restlet.
The issue is in Restlet's ReadableChunkingChannel. In order to chunk an
existing representation, it needs to first decode it if it's encoded. In the
case of Encoding.DEFLATE, it would thus use
I'll just quickly point out there is *another* bug here.
Because Restlet's EncodeRepresentation class does not use nowrap encoding,
DEFLATE encoding will be broken for certain versions of Internet Explorer.
This bug may well very have existed in Restlet for a long time.
-Tal
I'm getting these exceptions occasionally on a few specific resources, not sure
yet how to reproduce. Has anyone else seen them and have any information?
I'm getting them both the internal connector and with Jetty.
Stack trace example:
2012-08-28 22:23:19,233: WARN
I've been experimenting with 2.1 for a while with a few big Restlet
applications.
I want to point out that 2.1-RC6 is the first version of Restlet (including all
the 2.0 line!) in which I could use Directory over the internal connector
without any response hangs. Hooray, it may be possible to
I was about to do this myself, but thanks very much. :) :)
Why not have 2.1 use Jetty 8?
Related: I recommend updating the Jackson plugin to use the 2.0 line. The API
is the same, but there is a namespace change. If you update it, it would allow
users to upgrade the jar without problems.
To add information from my testing:
Restlet 2.1rc5 seems to work fine with Jetty 7.5.4, so I imagine it would be
trivial to update Jetty to that.
However, it does not work with Jetty 7.6 nor Jetty 8. There are likely API
updates necessary.
I hope Restlet 2.1 can be released with support for
Would anybody on the list happen to know the story behind the patched version
of Restlet 1.1.6 that's included in Nexus 2.0.2? It is marked version
1.1.6-SONATYPE-5348-V4.
From what I can tell, they were trying to solve a problem with the Apache HTTP
Client extension (they patched that
Jerome,
You make a lot of sense.
I agree with you that Jetty's solution is complicated, but I was 1) hoping we
could do it more straightforwardly in Restlet (possibly a naive hope), and 2) a
graph (and other) solutions would have their own complexity. There's really no
simple way out of this.
I see.
Well, how about this:
Perhaps setAutoCommit(false) might be the wrong approach. If anybody else along
the chain tries to commit, it should fail somehow. How, then, would
response.commit() know when it's time to really, truly commit?
My idea is to make a commitment to commit (ha!) via a
I would have two answers:
1) Isn't that the price to pay for asynchronicity, and the desire of the user?
The whole point is to implicate a different set of threads into communication
with the client. Of course, hybrid thread-pool-plus-event-driven servers come
to mind, which queue up event
pop those afterHandles and
call them?
Afaict, this isn't in yet, so I think it would be safer to say that asynch
I/O is still in preview mode for 2.1. Am I being too pessimistic?
--tim
On Thu, Dec 22, 2011 at 12:56 AM, Tal Liron tal dot liron at threecrickets
Has this issue ever been resolved? Should I open a bug for it?
Sigh, it's been a long two days.
The bottom line is that if you use Client or ClientResource over the
Apache HTTP Client, you better not use followingRedirect=true, or else
you'll get hanging threads due to connections not
html style=direction: ltr;
head
meta http-equiv=content-type content=text/html;
charset=ISO-8859-1stylebody
p { margin-bottom: 0cm; margin-top: 0pt; } /style
/head
body style=direction: ltr;
bidimailui-detected-decoding-type=latin-charset bgcolor=#FF
text=#00
I apologize, Jerome. I thought it would be interesting for Restlet users to see
how Prudence was progressing. There is not a lot of traffic on the mailing list
these days, so I thought some news would be nice! I will refrain from posting
about minor releases.
-Tal
This is a maintenance release that mostly involves upgrading a few dependencies
and improving various pain points in the distributions (many of those are
thanks to enthusiastic feedback from Beth Marston). It should now be easier
than ever before to hit the ground rolling with Prudence.
This
It's a standard Subversion repo on Google Code, so I think it should work with
Beanstalk!
(I've been considering switching to Mercurial, but I think Subversion serves
the most important needs for now.)
I'm not married to MongoDB, but we are having a sordid love affair. :) The
NoSQL database
web development framework tastes better than yours.
Yours,
Tal Liron,
Three Crickets LLC
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2781974
If you live in Chicago, come to the July 6 2011 MongoDB meetup, where I will be
presenting Savory, and showing some wild Ext JS and Sencha Touch tricks:
http://www.meetup.com/Chicago-MongoDB-User-Group/events/21369271/
--
Fabian,
This is the $1,000,000 question, quite literally. I happen to think that
deployment -- a term often considered by engineers only at the very end of
their project -- is more likely close to 50% of their work effort. I've never
seen any real-life project for real people (other than some
Sigh, it's been a long two days.
The bottom line is that if you use Client or ClientResource over the
Apache HTTP Client, you better not use followingRedirect=true, or else
you'll get hanging threads due to connections not being returned to the
Apache Client's connection pool.
The issue is
I can confirm that this is also true for Restlet 2.0.6. The blog
announcement indicated that Jetty was upgraded, but I guess this
happened only in the 2.1 branch. Jetty 7.3 does not work in Restlet 2.0.
-Tal
On 03/18/2011 03:09 PM, John Karp wrote:
I found the problem. Apparently
You can check out the daemon support page for Prudence (which is based
on Restlet):
http://threecrickets.com/prudence/manual/daemon/
Prudence comes with working configuration files for Tanuki's Wrapper and
for YAJSW. It comes with Apache Commons Daemon ready to run, with a
rather
This looks terrific, Dave! Congratulations -- it's always a great
feeling to finally get a big project out the door.
I am especially interested in how you used OSGi for deployment. I'm
still torn about the costs vs. the benefits. The idea seems great in
theory, but it seems to me to have
There are no real limitations. Using Apache as a reverse proxy in front
of Restlet should work just fine, actually better than having Restlet
answer internet requests directly.
Restlet does tend to be stricter about HTTP header formats than most
HTTP servers. Things that Apache's mod_php
Hmm, I'm having some more issues with the Apache HTTP client. This is a
URL that works fine with other HTTP clients.
Restlet 2.0.4 SE.
Here's the relevant stack trace. Any ideas?
2011-01-31 03:45:49,553: WARN [org.restlet.Component.Client] Invalid
tag format detected:
I'm getting a lot of these exceptions when accessing perfectly happy
internet sites, such as Yahoo! and LiveJournal.
It seems that various people on the net have problems with similar
problems with Apache HTTP Client on Android, but in this case I'm using
Restlet 2.0 JSE. Any ideas or
SimpleDateFormat is not thread-safe -- you have no choice but to 1)
re-create it per request, or 2) use thread-locals.
-Tal
On 01/24/2011 09:05 AM, Chris Davis wrote:
Hello,
I have been profiling my android app that uses android restlet client
2.0.3.
I can see from the profile (image
to personally thank Jerome, Thierry and everyone who assisted
on the Restlet mailing list during development! It's been a wonderful
journey.
And now, it's time to think of Prudence 1.1...
Sincerely,
Tal Liron and Three Crickets
--
http
I have been developing regularly using Restlet (via Prudence for
JavaScript) and MongoDB for a while, and strongly recommend it.
Check out the MongoVision project as an example. The server-side code is
ridiculously simple:
http://code.google.com/p/mongo-vision/
(For web development, the
This talk has been postponed to next Wednesday, Jan 19th. If you're in the
Chicago area and are interested in using Restlet with Clojure, join us!
http://www.meetup.com/Chicago-Clojure/calendar/15911747/http://www.meetup.com/Chicago-Clojure/calendar/15623004/
On Thu, Dec 2, 2010 at 5:10 PM, Tal
has been postponed to next Wednesday, Jan 19th. If you're in the
Chicago area and are interested in using Restlet with Clojure, join us!
http://www.meetup.com/Chicago-Clojure/calendar/15911747/http://www.meetup.com/Chicago-Clojure/calendar/15623004/
On Thu, Dec 2, 2010 at 5:10 PM, Tal Liron
So, what do you think about this pseudo-code to demonstrate the use of
ClientResource? (My experience has shown this to hang applications...)
function getText(url) {
var resource = new ClientResource(url)
var representation = resource.get()
if (representation) {
var text;
try {
, Tal Liron wrote:
pool.) It's probably best to employ a try-finally paradigm, where the
try clause contains as little code as possible, and the finally clause
releases the response. See the example below.
var fixture
var resource =
document.external('file:///myfiles/fixture.json','application
I took me a while to debug this problem, and I agree it could be made
clearer. Here's what I wrote in the Prudence documentation, and would be
happy if anyone could correct me if I'm wrong:
Important: The semantics of ClientResource require you to explicitly release
the response as soon as you're
Like David, I also recommend requiring trailing slashes for *everything*. In
fact, I'm annoyed that the URI spec lets you get away without using them...
it's a recipe for so much confusion, especially in relative paths
(HTML/CSS). This is a vestige from the days in which filesystems were mapped
Anybody?
I sometimes think I'm the only Restlet user who pushes RIAP to these
extremes... :)
On Sun, Nov 21, 2010 at 11:24 PM, Tal Liron tal.li...@threecrickets.comwrote:
I have an representation that writes binary data. It works fine in HTTP,
but in RIAP I get this exception when I try
In case you're interested, I'll be giving a talk on December 15th
(Wednesday) at 6pm, at ThoughtWorks (200 E. Randolph).
The Clojure edition is Prudence's most exciting: the combination of
Prudence's high-concurrency Restlet container and Clojure's persistent data
structure promises very robust,
This is a useful discussion! I think newcomers to REST, especially those
trained in RPC thinking, find the URI space paradigm to baffling.
Unlike pros like us who swim gracefully in its waters. :)
That's a good point. Per-resource docs won't scale, or at least not
without some tool to
I can't find any mention of this in the HTTP/1.1 spec under PUT and
DELETE. What am I missing?
Hm, I remembered that the requirement for both was that the parent URI
exist. For example, that you can't PUT to /items/box/ unless /items/
exists. But, a quick look at the spec now and I can't
more or less read the API right out of there.
--tim
On Fri, Nov 26, 2010 at 4:37 PM, Tal Liron
tal.li...@threecrickets.com mailto:tal.li...@threecrickets.com wrote:
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
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
I have an representation that writes binary data. It works fine in HTTP,
but in RIAP I get this exception when I try to exhaust the stream
(Restlet 2.0.2):
java.io.IOException: Timeout while reading from the queue-based input
stream
at
There's nothing in REST for or against sessions -- that's not its
domain. Your higher level app can definitely have sessions.
I do not recommend renewing your cookie for every request to keep the
session from expiring. Instead, have your cookie store a session ID, and
maintain a session table
Would this bug affect the 2.0 branch at all?
On 11/17/2010 05:33 AM, Thierry Boileau wrote:
Hello Tom,
thanks a lot for your help, the fix is available in the svn repository.
Best regards,
Thierry Boileau
--
My problem ended up being Grizzly (version 1.9.21).
Switching to Jetty made the problem disappear, at least for the past 24
hours. Will keep you posted.
I don't know if the issue is Grizzly itself or the Restlet connector,
but this is a production system I can't play around with and test.
Absolutely, and it works great!
Though I do recommend using the Apache HTTP client connector for good
performance and secure connection support. There are a few library
dependencies to get it to work, so make sure you get them.
-Tal
On 11/07/2010 01:19 PM, deuce4 wrote:
I am wondering of
I'll only say that without caching somewhere along the line, making any
kind of front-facing UIs with Restlet is going to be painful. When this
comes (Restlet 2.1?), the proper Restlety route for this may suggest
itself. fetchCalendar may cache, but does wrapIfHtml cache?
Though, I do like
Exactly. You would still want two layers for everyday production
applications, even if you have just one Restlet node.
Upgrading your app, for example -- you have Varnish show a under
maintenance screen while you swap out your Restlet nodes.
Perhaps it looks appealing to have both layers in
The Internet is a wild place. :) You will get hits from all kinds of bots,
from search engines to trackers of various sorts to spies to malicious
attacks. The Internet also has a long memory. Years from now, you will still
get hits for pages that have been removed from your application today.
code.
-Tal
On Mon, Sep 13, 2010 at 3:44 AM, Vincent Nonnenmacher
vincent.nonnenmac...@agentspace.com wrote:
On 12/09/10 02:39, Tal Liron wrote:
I'm very happy to announce the first public release candidate of
Prudence, an open source web development platform based on Restlet 2.0.
http
Vincent,
This is handled in Prudence using capturing:
http://threecrickets.com/prudence/manual/routing/#toc-Subsubsection-93
Note that the capturing API, like all other Restlet sugar, is available in
the tiny standalone Prudence jar.
-Tal
On Fri, Sep 10, 2010 at 7:54 AM, Vincent Nonnenmacher
is also included.
Enjoy! And please join the Prudence community:
http://groups.google.com/group/prudence-community
Special thanks go to Noelios, and especially Jérôme, for cultivating
such a vibrant community around Restlet. It's a solid foundation.
-Tal Liron
Kauri is impressive!
Also check out Prudence. If all goes well, we will have a 1.0 release
candidate this weekend. :)
http://threecrickets.com/prudence/
On 09/10/2010 02:15 AM, Marc Portier wrote:
you might want to give http://kauriproject.org a try
it has restlet and all its goodies
Just a quick note on changed behavior I noticed in 2.0.1 --
If you throw a ResourceException that has a cause, the cause is now sent
to the status service for processing into a new status. If you don't
have explicit support for this, you'll likely get a 500 error, thus
overriding whatever
On Wed, Jul 28, 2010 at 7:43 PM, Tal Liron
tal.li...@threecrickets.com mailto:tal.li...@threecrickets.com
wrote:
I've handled it differently for Prudence: I create static
unified/minifed files on-the-fly to be served via a Directory. If you
request all.min.js, all .js files
Here's an article I wrote as an introduction to REST:
http://threecrickets.com/prudence/rest/
-Tal
On 08/13/2010 12:47 AM, sic wrote:
I hope to understand not the restlet but the concept of REST itself, sorry
for that.
What's the meaning of the REST compared with HTTP using commonly all
I've handled it differently for Prudence: I create static
unified/minifed files on-the-fly to be served via a Directory. If you
request all.min.js, all .js files in that directory are unified (in
alphabetical order) and minifed. The filter can detect if any of the
source files has been
I've noticed that Request.getRootRef() returns null in Restlet 2.0.0.
I haven't been able to find out what triggers this, but will try to dig
more...
-Tal
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2637021
I've managed to trace this -- the effect is specific to the RIAP
protocol. Could this be intentional or is it a bug?
On 07/22/2010 02:10 PM, Tal Liron wrote:
I've noticed that Request.getRootRef() returns null in Restlet 2.0.0.
I haven't been able to find out what triggers this, but will try
to handle control
flow, but I can't think of anything better off-hand.
--tim
On Sat, May 22, 2010 at 8:05 PM, Tal Liron tal.li...@threecrickets.com
wrote:
Hi Jerome,
2. There is a TaskService associated to your application that you could
leverage. It separates threads usage from tasks
Great stuff, Eric. I will experiment with this. I would love for Prudence to
have a matching client-side API.
By the way, take a look at Ext-JS -- recent versions have really well
thought-out RESTful widgets. You'll need to have your Restlet resources
aware of the Ext-JS requirements, but this is
This is good news!
Until this is available, I would like to suggest trying out Prudence for
JavaScript. It's not intended as a Restlet edition, but instead a RESTful
platform, which happens to be fueled by the real Restlet (JSE edition) for
Java, via the Rhino JavaScript engine. It thus will
As long as you're part of the decision-making process for Restlet,
then I'm OK with it.
The caveat is that people don't always understand how to use the
configuration parameters of ThreadPoolExecutor. There was an exchange
on the concurrency-interest mailing list recently that brought this
Suitably ambitious!
I'm sure we all have our little issues that we'd like to see prioritized...
Mine is that I would like to see some instrumentation of the servers. My
specialization is super-scalable systems (the cloud) and this would
make Restlet very sweet for me:
I've created an extension of Form called FormWithFiles for Prudence:
http://prudence.tigris.org/source/browse/prudence/trunk/java/com.threecrickets.prudence/src/com/threecrickets/prudence/util/FormWithFiles.java
people
to think about it as a natural part of the Restlet engine.
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com
-Message d'origine-
De : Tal Liron [mailto:tal.li...@threecrickets.com]
Envoyé
Hi Jerome,
2. There is a TaskService associated to your application that you could
leverage. It separates threads usage from tasks to process (such as
committing responses).
I've tried this, but there is a concurrency problem with this pattern in
ServerResource --
If I set autoCommiting to
Thought I've followed what I could of the progress on asynchronous
support, I have a few interdependent questions and suggestions.
1. On the one hand, I really like how simple asynchronicity is handled.
I can defer my response to later (from another thread). But, Restlet
provides no tools to
I've solved this using something I call a FallbackRouter, which
internally uses a restlet I call a Fallback. It knows how to test
different targets in series until it finds one that succeeds. The
FallbackRouter is smart enough to know when you are attaching multiple
identical paths, and the
to tie these
together.
Anyhow I have a stateful client, now I just need to figure out the best
way to synchronize clients and I think you are right; CPU goes before
bandwidth in my case too.
Maybe a fullstate monopacket protocol?
Cheers,
/marc
On Wed, 21 Apr 2010, Tal Liron wrote:
REST
A common solution I use is to have my loadbalancer (I like PerlBal)
handles HTTPS divert HTTP and HTTPS to different ports, for example 80
for HTTP and 81 for HTTPS. You can run your Restlet component with two
servers to answer both of these, and then test for which port requests
are coming
REST services are only as chatty as however you define your resources.
I've seen many REST architectures suffering from a failure of imagination:
the architects assume that resource has to have a one-to-one mapping with
database row or other concrete entity, when in fact there is not such
I've been following this with interest, though haven't had time to
look at it... Thanks for the excellent debugging, David and Bruno!
On 03/26/2010 09:16 AM, Bruno Harbulot wrote:
Hi Dave,
On 25/03/2010 21:47, David Fogel wrote:
Hi Bruno-
So, I got Jetty working as the connector, and yes,
Just letting you know all seems to work well now! Test revision 6392.
On 03/01/2010 09:48 AM, Thierry Boileau wrote:
Hello Tal,
thanks for your report. There was a bug in the Protocol class which
causes the generation of bad responses with the RIAP protocol.
This should work better now. Let
I've been seeing hangs on GET, too. Unfortunately, can't provide debug
information for this particular project ... I hacked a quick workaround
to avoid it.
Seems to do with the fixes Thierry made to protocol handling.
On 03/03/2010 03:50 PM, webp...@tigris.org wrote:
Jerome,
I have the same
Almost there. :)
Restlet's ClientResource works fine.
With Firefox, the request does reach the target resource, but something
odd is going on with the response. Firefox just hangs waiting for the
request to close. Also, and this is probably related, rather than
getting just my string
Hi Thierry --
The documentation for the URI template variables is so deeply hidden
(Resolver API doc) that I always have trouble finding it. My
recommendation is to put it somewhere much more obvious, possibly even
in the first Resource tutorials, and to document it more with
examples. It's
True.
So, I guess the only way to remove turn off routes/restlets is to detach
them?
On Wed, Feb 24, 2010 at 2:33 PM, Stephan Koops stephan.ko...@web.de wrote:
Hi Tal,
you could do some initialization and finalization work in your own
Restlets.
best regards
Stephan
Tal Liron schrieb
Thanks!
Would love to test and confirm, but Restlet won't build (revision 6159).
My error:
[javac]
/Depot/Projects/Collaborative/Restlet/build/temp/android/modules/org.restlet.ext.odata/src/org/restlet/ext/odata/internal/FeedParser.java:362:
cannot find symbol
[javac] symbol :
It seems like I cannot use a Redirector to an RIAP URI.
For example:
router.attach(/note/{id}), new Redirector(component.context,
riap://component/myapp/note, Redirector.MODE_SERVER_DISPATCHER));
Is this intentional? Can anyone think of a simple workaround?
The use case is to have a different
Ah!
Further digging showed me that what happened was that the behavior of
catching thrown ResourceExceptions from a ServerResource has changed.
Now, if the exception has a cause, then the error always becomes 500.
This was not previously the case... If this is planned behavior, great,
but
This seems to be true of revision 6132.
Is this intentional, or a regression bug?
-Tal
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2447935
It seems to me that what's going on is that thrown ResourceExceptions
are not getting their Status set to the Response.
On 02/15/2010 05:58 PM, Tal Liron wrote:
This seems to be true of revision 6132.
Is this intentional, or a regression bug?
-Tal
So, nobody provided a better solution, but here's mine, with source code
straight out of the Prudence project!
I call it a FallbackRouter, an extension of the standard Restlet router, and
pretty much a drop-in replacement for it in most circumstances. Whenever you
attach new targets to it, it
Unfortunately, I can confirm that Andrzej's beforeSend fix is the way to
go on this one. Been doing it for a while now...
@Thierry: The dataType parameter in .ajax is just for jQuery to handle
the response. It doesn't actually do anything for jQuery's request.
An additional jQuery quirk to
1 - 100 of 157 matches
Mail list logo
