Hello Robert, Ioanis,
did you try to use the simple or jetty extensions? They provide a HTTP
server connector that we consider to be more stable than the internal HTTP
connector which is fine for development but not for production systems. We
are on the way to provide a good one with the 2.1
Hello,
from what I see, the standard way of configuring JAXB is made via a
jaxb.properties file (generated by MOXy generally) included inside the
bean package.
I contains this kind of property whick refers to MOXy :
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
Ioannis Mavroukakis wrote:
Hi Robert, you say most so that makes me assume some of them work.
What are the functional differences between the ones that do work and the
ones that don't ?
I tracked down the problem to some code I used to add an additional HTTP
header. I found the code here:
Hi Thierry,
Yes with regards to the jetty extension. I don't use the Restlet client for my
testing, I use loadUI.
Thanks,
Ioannis
On 11 Jul 2012, at 08:24, Thierry Boileau thierry.boil...@restlet.com wrote:
Hello Robert, Ioanis,
did you try to use the simple or jetty extensions? They
It should be mentioned in the migration guide, but it isn't a bug, it's a
change in the method signature.
--tim
On Tue, Jul 10, 2012 at 10:41 PM, Robert Brewer rbre...@lava.net wrote:
Ioannis Mavroukakis wrote:
Hi Robert, you say most so that makes me assume some of them work.
What are the
Hello all,
thanks to the contributation of Danny Leshem, a potential vulnerability has
been fixed today in the current snapshot of the 2.0 and 2.1 branches, and
the current master (future release 2.2).
This vulnerability may be exploited when generating the representation of a
failure response.
Hello all,
thanks for mentioning this topic, I've updated the migration guide.
Best regards,
Thierry Boileau
--tim
On Tue, Jul 10, 2012 at 10:41 PM, Robert Brewer rbre...@lava.net wrote:
Ioannis Mavroukakis wrote:
Hi Robert, you say most so that makes me assume some of them work.
I've updated the snippet in https://pastebin.com/3nzsjFi1 to demonstrate a
potential workaround using a custom StatusService and special client-side
handling. This example just deals with a StringRepresentation to pass a
custom error status description, but the technique could be generalized to
Thanks for the quick response. So setting the context factory with
jaxb.properties does work. But I want to initialize my own JaxbContext and
tell restlet to use that context. Instead of using the context instanciated
in JaxbRepresentation class.I want to do this because i want to utilize
MOXy's
Tim:
Thanks for the update to your code and for the explanation. While my code
is a little different than yours, sending along a StringRepresentation of
the error in the response's entity and then having the client look in the
entity in case of an error worked just fine for me.
Would be much
On Wed, Jul 11, 2012 at 8:04 PM, Richard Berger rich...@landisfamily.orgwrote:
Do you think that this problem has persisted this long due to the lack of
clients built with Restlet (vs. the much larger number of servers built
with Restlet)?
That's not really a fair question: You're leading
Excellent points - I didn't quite realize that the Status was restlet
specific and now it makes more sense to me that (as you put it) the illusion
isn't extended all the way to Exceptions.
Thanks for your ongoing assistance and information!
RB
--
View this message in context:
12 matches
Mail list logo
