You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(16) |
Apr
(18) |
May
(13) |
Jun
(100) |
Jul
(165) |
Aug
(53) |
Sep
(41) |
Oct
(84) |
Nov
(113) |
Dec
(171) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(84) |
Feb
(30) |
Mar
(75) |
Apr
(113) |
May
(87) |
Jun
(96) |
Jul
(127) |
Aug
(106) |
Sep
(191) |
Oct
(142) |
Nov
(106) |
Dec
(83) |
| 2010 |
Jan
(62) |
Feb
(93) |
Mar
(92) |
Apr
(58) |
May
(52) |
Jun
(104) |
Jul
(109) |
Aug
(94) |
Sep
(75) |
Oct
(54) |
Nov
(65) |
Dec
(38) |
| 2011 |
Jan
(53) |
Feb
(84) |
Mar
(95) |
Apr
(24) |
May
(10) |
Jun
(49) |
Jul
(74) |
Aug
(23) |
Sep
(67) |
Oct
(21) |
Nov
(62) |
Dec
(50) |
| 2012 |
Jan
(26) |
Feb
(7) |
Mar
(9) |
Apr
(5) |
May
(13) |
Jun
(7) |
Jul
(18) |
Aug
(48) |
Sep
(58) |
Oct
(79) |
Nov
(19) |
Dec
(15) |
| 2013 |
Jan
(33) |
Feb
(21) |
Mar
(10) |
Apr
(22) |
May
(39) |
Jun
(31) |
Jul
(15) |
Aug
(6) |
Sep
(8) |
Oct
(1) |
Nov
(4) |
Dec
(3) |
| 2014 |
Jan
(17) |
Feb
(18) |
Mar
(15) |
Apr
(12) |
May
(11) |
Jun
(3) |
Jul
(10) |
Aug
(2) |
Sep
(3) |
Oct
(4) |
Nov
(4) |
Dec
(1) |
| 2015 |
Jan
|
Feb
(6) |
Mar
(5) |
Apr
(13) |
May
(2) |
Jun
(3) |
Jul
(1) |
Aug
(2) |
Sep
(6) |
Oct
(12) |
Nov
(12) |
Dec
(12) |
| 2016 |
Jan
(10) |
Feb
(3) |
Mar
(8) |
Apr
(4) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Christian B. <chr...@gm...> - 2008-08-15 05:43:02
|
> Probably the best solution would be to implement ExceptionMapper
> handling in Resteasy as some kind of filter I could enable/disable/
> extend.
Some pseudo code to illustrate this, current situation:
// Wrap in RESTEasy contexts
try {
ResteasyProviderFactory.pushContext(HttpServletRequest.class,
request);
...
// Wrap in Seam contexts
new ContextualHttpServletRequest(request) {
UriInfoImpl uriInfo = // Do stuff
dispatcher.getDispatcher().invoke(in, theResponse);
}
} finally {
ResteasyProviderFactory.clearContextData();
}
Ideally I would get access to the ExceptionMapper invocation like
this, the exception needs to bubble out of dispatcher.invoke():
// Wrap in RESTEasy contexts
try {
ResteasyProviderFactory.pushContext(HttpServletRequest.class,
request);
...
// Wrap in Seam contexts
new ContextualHttpServletRequest(request) {
UriInfoImpl uriInfo = // Do stuff
dispatcher.getDispatcher().invoke(in, theResponse);
}
} catch (Exception ex) {
return exceptionMapper.getResponse(ex);
} finally {
ResteasyProviderFactory.clearContextData();
}
Anything else is going to be significantly more effort to integrate
into the Seam filter/call stack.
|
|
From: Bill B. <bb...@re...> - 2008-08-15 02:05:33
|
I've implemented a simple test injecting HttpServletRequest using
Resteasy Beta 5. I can't reproduce your problem and it works fine for
me so I don't know what to tell you. Are you using Beta 5?
FYI A better way to do this would be:
@ConsumeMime("application/x-www-form-urlencoded")
public String submitForm(MultivaluedMap<String, String> form) {
...
}
You don't need the @ConsumeMime unless your resource can have different
data formats posted to it other than form.
Pranav Parikh wrote:
> Hi,
>
> I'm a beginner in REST.I dont know if this is a right place to post this
> message but I could not find any other place so posting it here.
>
> I'm implementing RESTful Web services for my application. I'm facing a
> few problems when submitting the HTML form using the HTTP POST method.
> I'm not able to retrieve the form parameters I submit using the POST
> method. The "request" object is always null.
>
> My servlet code is as follows
>
> import javax.servlet.http.HttpServletRequest;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> import javax.ws.rs.ProduceMime;
> import javax.ws.rs.core.Context;
>
> @POST
> @Path("/submitform")
> @ProduceMime("text/plain")
> public String submitForm(@Context HttpServletRequest request){
>
> logger.info <http://logger.info>("In submitform"+request);
>
> if(request!=null){ // the control never goes inside if
>
> String name = request.getParameter("name");
> String surname = request.getParameter("surname");
>
> logger.info
> <http://logger.info>("Name::"+name+",Surname::"+surname);
> return "Name::"+name+",Surname::"+surname;
>
> }
> return "request is null"; // This gets returned always
>
> }
>
>
> My HTML looks like
>
> <html>
> <title>A Test Page
> </title>
>
> <form method="post" name="form1"
> action="https://localhost:8443/rest/submitform/">
> <table>
> <tr>
> <td>Name::
> </td>
>
> <td>
> <input type=text name="name" value="">
> </td>
> </tr>
>
> <tr>
> <td>Surname::
> </td>
>
> <td>
> <input type=text name="surname" value="">
> </td>
> </tr>
>
> <tr>
> <td align=center colspan=2>
> <input type=submit name="submit" value="submit">
> </td>
> </tr>
>
>
> </table>
> </form>
> </html>
>
> Any kind help will be appreciated.
>
> Thanks,
> Pranav Parikh
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Pranav P. <pra...@gm...> - 2008-08-14 16:41:11
|
Hi,
I'm a beginner in REST.I dont know if this is a right place to post this
message but I could not find any other place so posting it here.
I'm implementing RESTful Web services for my application. I'm facing a few
problems when submitting the HTML form using the HTTP POST method. I'm not
able to retrieve the form parameters I submit using the POST method. The
"request" object is always null.
My servlet code is as follows
import javax.servlet.http.HttpServletRequest;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.ProduceMime;
import javax.ws.rs.core.Context;
@POST
@Path("/submitform")
@ProduceMime("text/plain")
public String submitForm(@Context HttpServletRequest request){
logger.info("In submitform"+request);
if(request!=null){ // the control never goes inside if
String name = request.getParameter("name");
String surname = request.getParameter("surname");
logger.info("Name::"+name+",Surname::"+surname);
return "Name::"+name+",Surname::"+surname;
}
return "request is null"; // This gets returned always
}
My HTML looks like
<html>
<title>A Test Page
</title>
<form method="post" name="form1" action="
https://localhost:8443/rest/submitform/">
<table>
<tr>
<td>Name::
</td>
<td>
<input type=text name="name" value="">
</td>
</tr>
<tr>
<td>Surname::
</td>
<td>
<input type=text name="surname" value="">
</td>
</tr>
<tr>
<td align=center colspan=2>
<input type=submit name="submit" value="submit">
</td>
</tr>
</table>
</form>
</html>
Any kind help will be appreciated.
Thanks,
Pranav Parikh
|
|
From: Christian B. <chr...@gm...> - 2008-08-14 12:51:26
|
I'm trying to integrate exception handling with Seam, a few issues: Resteasy doesn't implement the JAX RS exception handling nearest-type search: https://jira.jboss.org/jira/browse/RESTEASY-69 - so I can't write a generic ExceptionMapper<Exception> and delegate all of that to Seam. The second issue is that Resteasy swallows exceptions (and worse, it writes ugly logs): https://jira.jboss.org/jira/browse/RESTEASY-105 Seam has an ExceptionFilter, we need it to destroy contexts, end transactions, and so on. That filter will not run if dispatcher.invoke() does not throw an exception. I'm not sure how to best solve both issues. It's hard to implement a cleanup routine in Seam as a generic ExceptionMapper<Exception>, so I'd really like the regular ExceptionFilter to run. But that means that ExceptionMapper invocation has to occur outside of dispatcher.invoke(). Probably the best solution would be to implement ExceptionMapper handling in Resteasy as some kind of filter I could enable/disable/ extend. |
|
From: Bill B. <bb...@re...> - 2008-08-12 22:33:45
|
Ok, I've committed the 1st pass at a 0.10 spec upgrade. All unit tests
are passing. Here are some highlights:
* Path.encoded(), QueryParam.encoded() etc... don't exist anymore. Spec
specifies to encode strings by default and will no encode an %hex strings.
* Path.limited() is gone
* path parameter expressions now have the optional ability to define a
regular expression:
{foo: some regular expression}
{foo} results in a regular expression of ([^/]+)
This piece alone created a huge rewrite of pattern matching. Before I
was optimized on a per segment basis. Now that path parameter
expressions can span multiple segments I had to rewrite a lot.
* Some UriInfo methods have changed in behavior and signature
Hope I didn't break anybody's code too much :)
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Ryan J. M. <ry...@da...> - 2008-08-11 21:57:24
|
On Aug 11, 2008, at 12:41 PM, Bill Burke wrote:
> I'm fine with that.
>
> The JSON JAXBContexts existed as I thought users might want to use
> it outside of Readers/Writers.
True, I think we can keep the contexts, but we can consolidate the two
into one.
> FYI, I have a huge serious refactoring coming. I don't think it
> will effect providers, but most of the codebase is affected.
>
> Reason? Well, 0.10 changes a lot. Specifically:
>
> * how encoding works
> * No more Path.limited
> * Regular expression in @Paths
> * other minor API changes
>
> I've been working on it for a week now (mostly), still not done :(
Since you'll be making some changes to the core framework, it may make
more sense for me to way and fix any regression after your commit. I'm
going to hold off on any commits until those changes make their way in
unless you feel differently.
Ryan-
> Ryan J. McDonough wrote:
>> I'm finishing up the changes to the JAXB providers and had some
>> thoughts on the JSON Providers:
>> Current, the providers utilize a customized JAXBContext by
>> extending JAXBContext. There is a separate Context class for each
>> of Jettisons JSON conventions. Additionally, there's a custom
>> marshaller and unmarshaller for each convention type. What i'd like
>> to do is either get rid of the custom context and supporting
>> completely or consolidating the 2 context classes into one. We
>> could easily handle the Jettison mapping conventions via property
>> configuration rather than multiple classes. As far as configuration
>> goes, I've also been tinkering with the idea of an additional
>> annotation that can used on resource classes and methods. For
>> example:
>> @JSONConfig(value = JSONConvention.MAPPED,
>> ignoredElements = "foo")
>> public class OrderResource { ...
>> This would instruct the JSONProviders to use the mapped convention
>> and ignore <foo> elements. Additionally, we can also pass a array
>> of JSONToXml annotations that provides some fine grained control
>> over mapping process. On a related note, I also have an additional
>> JAXBConfig annotation which provides the following:
>> @JAXBConfig(packages = "org.jboss.resteasy.test.providers.jaxb.data",
>> useNameSpacePrefix = true,
>> validate = true,
>> namespaces = @XmlNs(
>> namespaceURI = "http://jboss.org/resteasy/test/providers/jaxb/generated/order
>> ", prefix = "o"))
>> @JSONConfig(value = JSONConvention.MAPPED,
>> ignoredElements = "foo")
>> public class OrderResource { ...
>> The useNameSpacePrefix attribute instructs RESTEasy to output the
>> XML using a namespace prefix. If the package is annotated with an
>> @XmlSchema annotation containing an @XmlNs annotation, the
>> namespace prefix will be lifted from there. However, the namespaces
>> array will take precedence over the package annotation. The
>> packages attribute allows you specify multiple package names. The
>> validate attribute will validate the XML against a provided XML
>> schema (attribute TBD).
>> I have most of this working at the moment but still need some more
>> time to wrap it up, but I wanted to get some feeler about the
>> aproaches here before continuing.
>> Ryan-
>> ------------------------------------------------------------------------
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
|
|
From: Bill B. <bb...@re...> - 2008-08-11 16:41:26
|
I'm fine with that.
The JSON JAXBContexts existed as I thought users might want to use it
outside of Readers/Writers.
FYI, I have a huge serious refactoring coming. I don't think it will
effect providers, but most of the codebase is affected.
Reason? Well, 0.10 changes a lot. Specifically:
* how encoding works
* No more Path.limited
* Regular expression in @Paths
* other minor API changes
I've been working on it for a week now (mostly), still not done :(
Ryan J. McDonough wrote:
> I'm finishing up the changes to the JAXB providers and had some thoughts
> on the JSON Providers:
>
> Current, the providers utilize a customized JAXBContext by extending
> JAXBContext. There is a separate Context class for each of Jettisons
> JSON conventions. Additionally, there's a custom marshaller and
> unmarshaller for each convention type. What i'd like to do is either get
> rid of the custom context and supporting completely or consolidating the
> 2 context classes into one. We could easily handle the Jettison mapping
> conventions via property configuration rather than multiple classes.
>
> As far as configuration goes, I've also been tinkering with the idea of
> an additional annotation that can used on resource classes and methods.
> For example:
>
> @JSONConfig(value = JSONConvention.MAPPED,
> ignoredElements = "foo")
> public class OrderResource { ...
>
> This would instruct the JSONProviders to use the mapped convention and
> ignore <foo> elements. Additionally, we can also pass a array
> of JSONToXml annotations that provides some fine grained control over
> mapping process.
>
> On a related note, I also have an additional JAXBConfig annotation which
> provides the following:
>
> @JAXBConfig(packages = "org.jboss.resteasy.test.providers.jaxb.data",
> useNameSpacePrefix = true,
> validate = true,
> namespaces =
> @XmlNs(
> namespaceURI =
> "http://jboss.org/resteasy/test/providers/jaxb/generated/order",
> prefix = "o"))
> @JSONConfig(value = JSONConvention.MAPPED,
> ignoredElements = "foo")
> public class OrderResource { ...
>
> The useNameSpacePrefix attribute instructs RESTEasy to output the XML
> using a namespace prefix. If the package is annotated with an @XmlSchema
> annotation containing an @XmlNs annotation, the namespace prefix will be
> lifted from there. However, the namespaces array will take precedence
> over the package annotation. The packages attribute allows you specify
> multiple package names. The validate attribute will validate the XML
> against a provided XML schema (attribute TBD).
>
> I have most of this working at the moment but still need some more time
> to wrap it up, but I wanted to get some feeler about the aproaches here
> before continuing.
>
> Ryan-
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
|
|
From: Paulo S. <pau...@gm...> - 2008-08-11 14:03:20
|
I'm having trouble making the problem easy to reproduce... it happens
sometimes, but not always.
One thing I noted that is different in your tests from ours is that you
don't have a method answering a URL directly (without sub-resources) and
using a spring injected bean, which is our case. I changed our local test to
use a sub-resource and the problem seemed to vanished, although I cannot be
100% sure yet.
I could not make your environment run here, but I'll write down what I think
could be a test case for my scenario, that could be inserted in the
SmokeTest.
This is the new block test:
GetMethod method = new GetMethod("
http://localhost:8080/spring-integration-test/direct/direct-call");
int status = client.executeMethod(method);
Assert.assertEquals(HttpResponseCodes.SC_OK, status);
Assert.assertEquals("DIRECT OK", method.getResponseBodyAsString());
method.releaseConnection();
To implement this, we could use the following bean:
@Path("/direct")
@Service("direct")
public class DirectBean {
@GET
@Path("direct-call")
public String directCall() {
return directSpring.getDirectResult();
}
@Resource(name="directSpring")
private DirectSpring directSpring;
}
and the spring bean:
@Service("directSpring")
public class DirectSpring {
public String getDirectResult() {
return "DIRECT OK";
}
}
does this make sense? Does it make the problem easier to understand?
PS.: If this really reproduces our problem, you may have to run the test
some times before the error appears, since it works sometimes.
[]s,
On Fri, Aug 8, 2008 at 7:20 PM, Bill Burke <bb...@re...> wrote:
> I cannot reproduce this problem. Do you have resteasy's scanning turned
> on? That would screw things up.
>
> (I sent you the code I tested with. If you didn't get it ping me
> privately).
>
> Paulo Siqueira wrote:
>
>> Sorry, I forgot to check the mailing list address in the CC...
>>
>> ---------- Forwarded message ----------
>> From: *Paulo Siqueira* <pau...@gm... <mailto:
>> pau...@gm...>>
>> Date: Fri, Aug 8, 2008 at 3:12 PM
>> Subject: Re: [Resteasy-developers] Problem with Spring and RestEasy
>> integration
>> To: Bill Burke <bb...@re... <mailto:bb...@re...>>
>>
>>
>> Hi Bill,
>>
>> We don't want an instance per request. It doesn't matter at moment
>> actually. The problem is that it isn't working even with everything
>> singleton (which is the default scope in singleton). Do we have to do
>> anything special to flag the RESTful beans as singleton?
>>
>> The main problem is the a dependency of the RESTful bean is not being
>> injected sometimes, although the bean itself is always there, thus giving us
>> NullPointers. In the example Fabio sent it would be the field "Seci" that
>> would end up being null.
>>
>> []s,
>>
>>
>> On Fri, Aug 8, 2008 at 12:16 PM, Bill Burke <bb...@re... <mailto:
>> bb...@re...>> wrote:
>>
>> So you want a instance per request model?
>>
>> I'm not that familiar with spring and the RestEasy code expects a
>> singleton model.
>>
>> I'll try out your code and see if I can figure things out.
>>
>> Fábio Serra wrote:
>> > Hi,
>> >
>> > We have a problem integrating RestEasy and Spring. It seems like
>> when
>> > two users access the same resource at the same time, the
>> > SpringContextLoaderListener is not injecting after the first
>> instance.
>> > After that all the resource instances aren't injected by Spring
>> causing
>> > NullPointerException at the spring injected objects.
>> >
>> > My web.xml is the same as the examples of this integration.
>> >
>> > Here is my resource class:
>> > @Service("locating")
>> > @Path("/")
>> > public class LocatingResource {
>> > public LocatingResource() {
>> > System.out.println("Instanciando....");
>> > }
>> >
>> > @GET
>> > @Path("locating")
>> > public String getLocating() {
>> > System.out.println("Class: "+ this);
>> > System.out.println("LOCATING...("+getSpringTest()+")");
>> > return getSeci().toString();
>> > }
>> >
>> > @Resource
>> > private Seci seci;
>> > public void setSeci( Seci seci ) {
>> > System.out.println("Classe1: " +this);
>> > System.out.println("SACI2: "+ seci);
>> > this.seci = seci;
>> > }
>> > public Seci getSeci() {
>> > return this.seci;
>> > }
>> > }
>> >
>> > My ApplicationContext.xml :
>> > <beans xmlns="http://www.springframework.org/schema/beans"
>> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> > xmlns:context="
>> http://www.springframework.org/schema/context"
>> > default-autowire="byName"
>> > xsi:schemaLocation="http://www.springframework.org/schema/beans
>> >
>> > http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
>> >
>> http://www.springframework.org/schema/context
>> >
>> >
>> http://www.springframework.org/schema/context/spring-context-2.5.xsd"
>> >
>> > >
>> > <context:annotation-config/>
>> > <context:spring-configured/>
>> > <context:component-scan base-package="padauan"
>> > annotation-config="true"/>
>> > </bean>
>> >
>> >
>> > Thanks,
>> >
>> > Fabio Serra
>> >
>> >
>>
>> ------------------------------------------------------------------------
>> > Novos endereços, o Yahoo! que você conhece. Crie um email novo
>> >
>> <
>> http://br.rd.yahoo.com/mail/taglines/mail/*http://br.new.mail.yahoo.com/addresses
>> >
>> > com a sua cara @ymail.com <http://ymail.com> ou @rocketmail.com
>> <http://rocketmail.com>.
>> >
>> >
>> >
>>
>> ------------------------------------------------------------------------
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> > This SF.Net email is sponsored by the Moblin Your Move
>> Developer's challenge
>> > Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> > Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>> >
>> >
>> >
>>
>> ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Resteasy-developers mailing list
>> > Res...@li...
>> <mailto:Res...@li...>
>> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> <mailto:Res...@li...>
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>>
>>
>>
>> --
>> Paulo R C Siqueira
>> SCJP / SCWCD
>> http://www.ipti.org.br
>> Contato: (11) 8149-5046
>>
>>
>>
>> --
>> Paulo R C Siqueira
>> SCJP / SCWCD
>> http://www.ipti.org.br
>> Contato: (11) 8149-5046
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
--
Paulo R C Siqueira
SCJP / SCWCD
http://www.ipti.org.br
Contato: (11) 8149-5046
|
|
From: Ryan J. M. <ry...@da...> - 2008-08-11 12:29:05
|
I'm finishing up the changes to the JAXB providers and had some
thoughts on the JSON Providers:
Current, the providers utilize a customized JAXBContext by extending
JAXBContext. There is a separate Context class for each of Jettisons
JSON conventions. Additionally, there's a custom marshaller and
unmarshaller for each convention type. What i'd like to do is either
get rid of the custom context and supporting completely or
consolidating the 2 context classes into one. We could easily handle
the Jettison mapping conventions via property configuration rather
than multiple classes.
As far as configuration goes, I've also been tinkering with the idea
of an additional annotation that can used on resource classes and
methods. For example:
@JSONConfig(value = JSONConvention.MAPPED,
ignoredElements = "foo")
public class OrderResource { ...
This would instruct the JSONProviders to use the mapped convention and
ignore <foo> elements. Additionally, we can also pass a array of
JSONToXml annotations that provides some fine grained control over
mapping process.
On a related note, I also have an additional JAXBConfig annotation
which provides the following:
@JAXBConfig(packages = "org.jboss.resteasy.test.providers.jaxb.data",
useNameSpacePrefix = true,
validate = true,
namespaces =
@XmlNs(
namespaceURI = "http://jboss.org/resteasy/test/providers/jaxb/generated/order
",
prefix = "o"))
@JSONConfig(value = JSONConvention.MAPPED,
ignoredElements = "foo")
public class OrderResource { ...
The useNameSpacePrefix attribute instructs RESTEasy to output the XML
using a namespace prefix. If the package is annotated with an
@XmlSchema annotation containing an @XmlNs annotation, the namespace
prefix will be lifted from there. However, the namespaces array will
take precedence over the package annotation. The packages attribute
allows you specify multiple package names. The validate attribute will
validate the XML against a provided XML schema (attribute TBD).
I have most of this working at the moment but still need some more
time to wrap it up, but I wanted to get some feeler about the
aproaches here before continuing.
Ryan- |
|
From: Andreas H. <a...@ho...> - 2008-08-10 11:49:17
|
Hello,
I recently created a resource that contained two @Path with limit set to
false. This failed with "It is illegal to have @Path.limited() == false on
your class then use a @Path on a method too".
This came from ResourceMethodRegistry.addResourceFactory, I'm not sure of the
correct behavior according to the spec, but it seems to me that it should be
possible to have several methods that are not limited within the same class.
I did a quick "fix" that I'm not even sure really works, but I have attached
the diff at the end of the e-mail for reference.
// Andreas
Index:
jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/ResourceMethodRegistry.java
===================================================================
---
jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/ResourceMethodRegistry.java
(revision 286)
+++
jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/ResourceMethodRegistry.java
(working copy)
@@ -126,11 +126,12 @@
* @param clazz specific class
* @param offset path segment offset. > 0 means we're within a locator.
*/
- public void addResourceFactory(ResourceFactory ref, String base, Class<?>
clazz, int offset, boolean limited)
+ public void addResourceFactory(ResourceFactory ref, String base, Class<?>
clazz, int offset, boolean limited0)
{
if (ref != null) ref.registered(new InjectorFactoryImpl(null,
providerFactory));
for (Method method : clazz.getMethods())
{
+ boolean limited = limited0;
Path path = method.getAnnotation(Path.class);
Set<String> httpMethods = IsHttpMethod.getHttpMethods(method);
if (path == null && httpMethods == null) continue;
|
|
From: Bill B. <bb...@re...> - 2008-08-08 22:20:45
|
I cannot reproduce this problem. Do you have resteasy's scanning turned
on? That would screw things up.
(I sent you the code I tested with. If you didn't get it ping me
privately).
Paulo Siqueira wrote:
> Sorry, I forgot to check the mailing list address in the CC...
>
> ---------- Forwarded message ----------
> From: *Paulo Siqueira* <pau...@gm...
> <mailto:pau...@gm...>>
> Date: Fri, Aug 8, 2008 at 3:12 PM
> Subject: Re: [Resteasy-developers] Problem with Spring and RestEasy
> integration
> To: Bill Burke <bb...@re... <mailto:bb...@re...>>
>
>
> Hi Bill,
>
> We don't want an instance per request. It doesn't matter at moment
> actually. The problem is that it isn't working even with everything
> singleton (which is the default scope in singleton). Do we have to do
> anything special to flag the RESTful beans as singleton?
>
> The main problem is the a dependency of the RESTful bean is not being
> injected sometimes, although the bean itself is always there, thus
> giving us NullPointers. In the example Fabio sent it would be the field
> "Seci" that would end up being null.
>
> []s,
>
>
> On Fri, Aug 8, 2008 at 12:16 PM, Bill Burke <bb...@re...
> <mailto:bb...@re...>> wrote:
>
> So you want a instance per request model?
>
> I'm not that familiar with spring and the RestEasy code expects a
> singleton model.
>
> I'll try out your code and see if I can figure things out.
>
> Fábio Serra wrote:
> > Hi,
> >
> > We have a problem integrating RestEasy and Spring. It seems like when
> > two users access the same resource at the same time, the
> > SpringContextLoaderListener is not injecting after the first
> instance.
> > After that all the resource instances aren't injected by Spring
> causing
> > NullPointerException at the spring injected objects.
> >
> > My web.xml is the same as the examples of this integration.
> >
> > Here is my resource class:
> > @Service("locating")
> > @Path("/")
> > public class LocatingResource {
> > public LocatingResource() {
> > System.out.println("Instanciando....");
> > }
> >
> > @GET
> > @Path("locating")
> > public String getLocating() {
> > System.out.println("Class: "+ this);
> > System.out.println("LOCATING...("+getSpringTest()+")");
> > return getSeci().toString();
> > }
> >
> > @Resource
> > private Seci seci;
> > public void setSeci( Seci seci ) {
> > System.out.println("Classe1: " +this);
> > System.out.println("SACI2: "+ seci);
> > this.seci = seci;
> > }
> > public Seci getSeci() {
> > return this.seci;
> > }
> > }
> >
> > My ApplicationContext.xml :
> > <beans xmlns="http://www.springframework.org/schema/beans"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > xmlns:context="http://www.springframework.org/schema/context"
> > default-autowire="byName"
> > xsi:schemaLocation="http://www.springframework.org/schema/beans
> >
> > http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
> >
> http://www.springframework.org/schema/context
> >
> > http://www.springframework.org/schema/context/spring-context-2.5.xsd"
> >
> > >
> > <context:annotation-config/>
> > <context:spring-configured/>
> > <context:component-scan base-package="padauan"
> > annotation-config="true"/>
> > </bean>
> >
> >
> > Thanks,
> >
> > Fabio Serra
> >
> >
> ------------------------------------------------------------------------
> > Novos endereços, o Yahoo! que você conhece. Crie um email novo
> >
> <http://br.rd.yahoo.com/mail/taglines/mail/*http://br.new.mail.yahoo.com/addresses>
> > com a sua cara @ymail.com <http://ymail.com> ou @rocketmail.com
> <http://rocketmail.com>.
> >
> >
> >
> ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in
> the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li...
> <mailto:Res...@li...>
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> <mailto:Res...@li...>
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>
>
>
> --
> Paulo R C Siqueira
> SCJP / SCWCD
> http://www.ipti.org.br
> Contato: (11) 8149-5046
>
>
>
> --
> Paulo R C Siqueira
> SCJP / SCWCD
> http://www.ipti.org.br
> Contato: (11) 8149-5046
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Bill B. <bb...@re...> - 2008-08-08 21:07:47
|
I cannot reproduce this problem. Please see attached jar for the
sourcecode example I made to test this. Do you have resteasy's scanning
turned on? That would screw things up.
Paulo Siqueira wrote:
> Sorry, I forgot to check the mailing list address in the CC...
>
> ---------- Forwarded message ----------
> From: *Paulo Siqueira* <pau...@gm...
> <mailto:pau...@gm...>>
> Date: Fri, Aug 8, 2008 at 3:12 PM
> Subject: Re: [Resteasy-developers] Problem with Spring and RestEasy
> integration
> To: Bill Burke <bb...@re... <mailto:bb...@re...>>
>
>
> Hi Bill,
>
> We don't want an instance per request. It doesn't matter at moment
> actually. The problem is that it isn't working even with everything
> singleton (which is the default scope in singleton). Do we have to do
> anything special to flag the RESTful beans as singleton?
>
> The main problem is the a dependency of the RESTful bean is not being
> injected sometimes, although the bean itself is always there, thus
> giving us NullPointers. In the example Fabio sent it would be the field
> "Seci" that would end up being null.
>
> []s,
>
>
> On Fri, Aug 8, 2008 at 12:16 PM, Bill Burke <bb...@re...
> <mailto:bb...@re...>> wrote:
>
> So you want a instance per request model?
>
> I'm not that familiar with spring and the RestEasy code expects a
> singleton model.
>
> I'll try out your code and see if I can figure things out.
>
> Fábio Serra wrote:
> > Hi,
> >
> > We have a problem integrating RestEasy and Spring. It seems like when
> > two users access the same resource at the same time, the
> > SpringContextLoaderListener is not injecting after the first
> instance.
> > After that all the resource instances aren't injected by Spring
> causing
> > NullPointerException at the spring injected objects.
> >
> > My web.xml is the same as the examples of this integration.
> >
> > Here is my resource class:
> > @Service("locating")
> > @Path("/")
> > public class LocatingResource {
> > public LocatingResource() {
> > System.out.println("Instanciando....");
> > }
> >
> > @GET
> > @Path("locating")
> > public String getLocating() {
> > System.out.println("Class: "+ this);
> > System.out.println("LOCATING...("+getSpringTest()+")");
> > return getSeci().toString();
> > }
> >
> > @Resource
> > private Seci seci;
> > public void setSeci( Seci seci ) {
> > System.out.println("Classe1: " +this);
> > System.out.println("SACI2: "+ seci);
> > this.seci = seci;
> > }
> > public Seci getSeci() {
> > return this.seci;
> > }
> > }
> >
> > My ApplicationContext.xml :
> > <beans xmlns="http://www.springframework.org/schema/beans"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > xmlns:context="http://www.springframework.org/schema/context"
> > default-autowire="byName"
> > xsi:schemaLocation="http://www.springframework.org/schema/beans
> >
> > http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
> >
> http://www.springframework.org/schema/context
> >
> > http://www.springframework.org/schema/context/spring-context-2.5.xsd"
> >
> > >
> > <context:annotation-config/>
> > <context:spring-configured/>
> > <context:component-scan base-package="padauan"
> > annotation-config="true"/>
> > </bean>
> >
> >
> > Thanks,
> >
> > Fabio Serra
> >
> >
> ------------------------------------------------------------------------
> > Novos endereços, o Yahoo! que você conhece. Crie um email novo
> >
> <http://br.rd.yahoo.com/mail/taglines/mail/*http://br.new.mail.yahoo.com/addresses>
> > com a sua cara @ymail.com <http://ymail.com> ou @rocketmail.com
> <http://rocketmail.com>.
> >
> >
> >
> ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in
> the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li...
> <mailto:Res...@li...>
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> <mailto:Res...@li...>
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>
>
>
> --
> Paulo R C Siqueira
> SCJP / SCWCD
> http://www.ipti.org.br
> Contato: (11) 8149-5046
>
>
>
> --
> Paulo R C Siqueira
> SCJP / SCWCD
> http://www.ipti.org.br
> Contato: (11) 8149-5046
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Paulo S. <pau...@gm...> - 2008-08-08 18:20:38
|
Sorry, I forgot to check the mailing list address in the CC...
---------- Forwarded message ----------
From: Paulo Siqueira <pau...@gm...>
Date: Fri, Aug 8, 2008 at 3:12 PM
Subject: Re: [Resteasy-developers] Problem with Spring and RestEasy
integration
To: Bill Burke <bb...@re...>
Hi Bill,
We don't want an instance per request. It doesn't matter at moment actually.
The problem is that it isn't working even with everything singleton (which
is the default scope in singleton). Do we have to do anything special to
flag the RESTful beans as singleton?
The main problem is the a dependency of the RESTful bean is not being
injected sometimes, although the bean itself is always there, thus giving us
NullPointers. In the example Fabio sent it would be the field "Seci" that
would end up being null.
[]s,
On Fri, Aug 8, 2008 at 12:16 PM, Bill Burke <bb...@re...> wrote:
> So you want a instance per request model?
>
> I'm not that familiar with spring and the RestEasy code expects a
> singleton model.
>
> I'll try out your code and see if I can figure things out.
>
> Fábio Serra wrote:
> > Hi,
> >
> > We have a problem integrating RestEasy and Spring. It seems like when
> > two users access the same resource at the same time, the
> > SpringContextLoaderListener is not injecting after the first instance.
> > After that all the resource instances aren't injected by Spring causing
> > NullPointerException at the spring injected objects.
> >
> > My web.xml is the same as the examples of this integration.
> >
> > Here is my resource class:
> > @Service("locating")
> > @Path("/")
> > public class LocatingResource {
> > public LocatingResource() {
> > System.out.println("Instanciando....");
> > }
> >
> > @GET
> > @Path("locating")
> > public String getLocating() {
> > System.out.println("Class: "+ this);
> > System.out.println("LOCATING...("+getSpringTest()+")");
> > return getSeci().toString();
> > }
> >
> > @Resource
> > private Seci seci;
> > public void setSeci( Seci seci ) {
> > System.out.println("Classe1: " +this);
> > System.out.println("SACI2: "+ seci);
> > this.seci = seci;
> > }
> > public Seci getSeci() {
> > return this.seci;
> > }
> > }
> >
> > My ApplicationContext.xml :
> > <beans xmlns="http://www.springframework.org/schema/beans"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > xmlns:context="http://www.springframework.org/schema/context"
> > default-autowire="byName"
> > xsi:schemaLocation="http://www.springframework.org/schema/beans
> >
> > http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
> >
> http://www.springframework.org/schema/context
> >
> > http://www.springframework.org/schema/context/spring-context-2.5.xsd"
> >
> > >
> > <context:annotation-config/>
> > <context:spring-configured/>
> > <context:component-scan base-package="padauan"
> > annotation-config="true"/>
> > </bean>
> >
> >
> > Thanks,
> >
> > Fabio Serra
> >
> > ------------------------------------------------------------------------
> > Novos endereços, o Yahoo! que você conhece. Crie um email novo
> > <
> http://br.rd.yahoo.com/mail/taglines/mail/*http://br.new.mail.yahoo.com/addresses
> >
> > com a sua cara @ymail.com ou @rocketmail.com.
> >
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Resteasy-developers mailing list
> > Res...@li...
> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
--
Paulo R C Siqueira
SCJP / SCWCD
http://www.ipti.org.br
Contato: (11) 8149-5046
--
Paulo R C Siqueira
SCJP / SCWCD
http://www.ipti.org.br
Contato: (11) 8149-5046
|
|
From: Bill B. <bb...@re...> - 2008-08-08 15:16:55
|
So you want a instance per request model?
I'm not that familiar with spring and the RestEasy code expects a
singleton model.
I'll try out your code and see if I can figure things out.
Fábio Serra wrote:
> Hi,
>
> We have a problem integrating RestEasy and Spring. It seems like when
> two users access the same resource at the same time, the
> SpringContextLoaderListener is not injecting after the first instance.
> After that all the resource instances aren't injected by Spring causing
> NullPointerException at the spring injected objects.
>
> My web.xml is the same as the examples of this integration.
>
> Here is my resource class:
> @Service("locating")
> @Path("/")
> public class LocatingResource {
> public LocatingResource() {
> System.out.println("Instanciando....");
> }
>
> @GET
> @Path("locating")
> public String getLocating() {
> System.out.println("Class: "+ this);
> System.out.println("LOCATING...("+getSpringTest()+")");
> return getSeci().toString();
> }
>
> @Resource
> private Seci seci;
> public void setSeci( Seci seci ) {
> System.out.println("Classe1: " +this);
> System.out.println("SACI2: "+ seci);
> this.seci = seci;
> }
> public Seci getSeci() {
> return this.seci;
> }
> }
>
> My ApplicationContext.xml :
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:context="http://www.springframework.org/schema/context"
> default-autowire="byName"
> xsi:schemaLocation="http://www.springframework.org/schema/beans
>
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
> http://www.springframework.org/schema/context
>
> http://www.springframework.org/schema/context/spring-context-2.5.xsd"
>
> >
> <context:annotation-config/>
> <context:spring-configured/>
> <context:component-scan base-package="padauan"
> annotation-config="true"/>
> </bean>
>
>
> Thanks,
>
> Fabio Serra
>
> ------------------------------------------------------------------------
> Novos endereços, o Yahoo! que você conhece. Crie um email novo
> <http://br.rd.yahoo.com/mail/taglines/mail/*http://br.new.mail.yahoo.com/addresses>
> com a sua cara @ymail.com ou @rocketmail.com.
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Fábio S. <fab...@ya...> - 2008-08-08 14:12:34
|
Hi,
We have a problem integrating RestEasy and Spring. It seems like when two users access the same resource at the same time, the SpringContextLoaderListener is not injecting after the first instance.
After that all the resource instances aren't injected by Spring causing NullPointerException at the spring injected objects.
My web.xml is the same as the examples of this integration.
Here is my resource class:
@Service("locating")
@Path("/")
public class LocatingResource {
public LocatingResource() {
System.out.println("Instanciando....");
}
@GET
@Path("locating")
public String getLocating() {
System.out.println("Class: "+ this);
System.out.println("LOCATING...("+getSpringTest()+")");
return getSeci().toString();
}
@Resource
private Seci seci;
public void setSeci( Seci seci ) {
System.out.println("Classe1: " +this);
System.out.println("SACI2: "+ seci);
this.seci = seci;
}
public Seci getSeci() {
return this.seci;
}
}
My ApplicationContext.xml :
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
default-autowire="byName"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd"
>
<context:annotation-config/>
<context:spring-configured/>
<context:component-scan base-package="padauan" annotation-config="true"/>
</bean>
Thanks,
Fabio Serra
Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses |
|
From: Bill B. <bb...@re...> - 2008-08-04 16:05:08
|
There were some changes to contextResolver as now it also takes into
account the mime type and I think annotation data to find the resolver
that creates the JAXBContext.
Ryan J. McDonough wrote:
> Bill,
>
> I was taking a look at how Jersey is using ContextResolver and they are
> not using it exclusively. In fact, they use a cache like we do, but they
> only use the cache if there is no ContextResolver in the request. So it
> works a like this:
>
> protected JAXBContext findJAXBContext(Class<?> type) throws JAXBException
> {
> if (contextResolver != null)
> {
> JAXBContext ctx = contextResolver.getContext(type);
> if (ctx != null)
> {
> return ctx;
> }
> }
> return JAXBCache.instance().getJAXBContext(type);
> }
>
> I had to make some changes to GenericDelegatingProxy so that it returns
> null instead of raising a RuntimeException. Otherwise, it was always
> returning a proxy even though there was no resolver present. All unit
> tests continue to execute and there doesn't appear to be any
> regressions. Please let me know if you see any issues with this change
> before I commit.
>
> Ryan-
>
>
>
>
> On Aug 1, 2008, at 5:58 PM, Bill Burke wrote:
>
>> There is no support for ContextResolver ATM. I'm upgrading to 0.10
>> and will add it in. Its gonna take me awhile though. If you are
>> going to work on the providers, just do what you were doing and I'll
>> refactor JAXB providers later to use a ContextResolver.
>>
>> FYI, big changes coming. Had to touch a LOT of files because of
>> upgrade to 0.9 :(.
>>
>> Ryan J. McDonough wrote:
>>> Ah! Now it all make more sense. This might be a better approach than
>>> additional annotations. Quick question though: do we support
>>> discovery of ContextResolver instances annotated with @Provider, or
>>> do we have to register them manually? And if it's manually, where
>>> does one do that in RESTEasy? I was poking around, but got lost :)
>>> Ryan-
>>> On Jul 31, 2008, at 2:00 PM, Bill Burke wrote:
>>>> After talking on the mail list a few weeks ago about ContextResolver (I
>>>> didn't know WTF it was for), I found that it exists solely to provide
>>>> pluggable JAXB contexts in the RI. I figure, since its there, we might
>>>> as well use it instead of JAXBCache.
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>> great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>> the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>>>> _______________________________________________
>>>> Resteasy-developers mailing list
>>>> Res...@li...
>>>> <mailto:Res...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Ryan J. M. <ry...@da...> - 2008-08-04 12:28:48
|
Bill,
I was taking a look at how Jersey is using ContextResolver and they
are not using it exclusively. In fact, they use a cache like we do,
but they only use the cache if there is no ContextResolver in the
request. So it works a like this:
protected JAXBContext findJAXBContext(Class<?> type) throws
JAXBException
{
if (contextResolver != null)
{
JAXBContext ctx = contextResolver.getContext(type);
if (ctx != null)
{
return ctx;
}
}
return JAXBCache.instance().getJAXBContext(type);
}
I had to make some changes to GenericDelegatingProxy so that it
returns null instead of raising a RuntimeException. Otherwise, it was
always returning a proxy even though there was no resolver present.
All unit tests continue to execute and there doesn't appear to be any
regressions. Please let me know if you see any issues with this change
before I commit.
Ryan-
On Aug 1, 2008, at 5:58 PM, Bill Burke wrote:
> There is no support for ContextResolver ATM. I'm upgrading to 0.10
> and will add it in. Its gonna take me awhile though. If you are
> going to work on the providers, just do what you were doing and I'll
> refactor JAXB providers later to use a ContextResolver.
>
> FYI, big changes coming. Had to touch a LOT of files because of
> upgrade to 0.9 :(.
>
> Ryan J. McDonough wrote:
>> Ah! Now it all make more sense. This might be a better approach
>> than additional annotations. Quick question though: do we support
>> discovery of ContextResolver instances annotated with @Provider, or
>> do we have to register them manually? And if it's manually, where
>> does one do that in RESTEasy? I was poking around, but got lost :)
>> Ryan-
>> On Jul 31, 2008, at 2:00 PM, Bill Burke wrote:
>>> After talking on the mail list a few weeks ago about
>>> ContextResolver (I
>>> didn't know WTF it was for), I found that it exists solely to
>>> provide
>>> pluggable JAXB contexts in the RI. I figure, since its there, we
>>> might
>>> as well use it instead of JAXBCache.
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Resteasy-developers mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
|
|
From: Ryan J. M. <ry...@da...> - 2008-08-04 12:23:28
|
One thing I'd like to do in order to provide better test coverage to the JAXB-based providers is to have some tests that can perform the following: Validate JAXB classes against an XML Schema Work with XJC generated from an XML Schema Validate against some pre-existing XML, Fastinfoset, and JSON instances The challenging thing is with the XJC generated classes because it the class generation always runs, no matter if you just want it to execute just for unit tests. This means that the test data would be packaged with the distribution, which is something we'd like to avoid. With that said, I' like to separate out the XJC portion into a subproject called something like "resteasy-test-data" that would simply contain JAXB generated classes and other test data. I wanted to float the idea first to see what people's opinions are on the subject. So far, it's working just dandy and I have classes generated from an XSD working. On a related note: I'm finishing up the JSON providers so that they are inline with the updates I made to the rest of the JAXB providers. I found some areas to refactor a bit more in order to make it more maintainable. With that said, please let me know if you're making any changes the JAXB, Fastinfoset, or JSON providers. Thanks! Ryan- |
|
From: Bill B. <bb...@re...> - 2008-08-02 02:05:22
|
Ok, I updated code to 0.9 of JSR311 api. I had to change a lot because: * @Produce/ConsumeMime was renamed to @Produces/@Consumes * Any interface that uses a language uses java.util.Locale instead of String * I removed the FormURLEoncdedObjectProvider in favor of @Form support as I discussed in previous email. * Added @FormParam support (from spec, not what Ryan had). -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Bill B. <bb...@re...> - 2008-08-01 23:26:03
|
Ok, i've implemented this minus the @Body thingy. Not sure how I want
to handle that.
Bill Burke wrote:
> I'm going to rewrite the @FormValues functionality that Ryan added.
> These will be the changes:
>
> * @FormValues renamed to @Form
> * org.jboss.resteasy.annotations.FormParam is redundant, spec now has a
> @FormParam annotation
> * @Form will only be a parameter, method, field annotation and used like
> any other @*Param annotation.
> * There will be no provider for it, instead it will be its own
> ParameterInjector
> * You can use any @*Param annotation within the @Form class you are
> injecting on any setter method, field, or constructor param of that class.
> * I'll add a new @Body annotation that allows you to inject a message
> body into a property of the form class.
>
> Here's an example:
>
> public class MyForm {
>
> @FormParam("foo")
> int foo;
>
> @HeaderParam("myHeader")
> public void setMyHeader(double val) {...}
>
>
> public MyForm(@Context Request request) {...}
>
> }
>
>
> @Path("/")
> public class MyResource
> {
>
> @POST
> public void post(@Form MyForm form) {...}
> }
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Bill B. <bb...@re...> - 2008-08-01 21:58:12
|
There is no support for ContextResolver ATM. I'm upgrading to 0.10 and will add it in. Its gonna take me awhile though. If you are going to work on the providers, just do what you were doing and I'll refactor JAXB providers later to use a ContextResolver. FYI, big changes coming. Had to touch a LOT of files because of upgrade to 0.9 :(. Ryan J. McDonough wrote: > Ah! Now it all make more sense. This might be a better approach than > additional annotations. Quick question though: do we support discovery > of ContextResolver instances annotated with @Provider, or do we have to > register them manually? And if it's manually, where does one do that in > RESTEasy? I was poking around, but got lost :) > > Ryan- > > > > On Jul 31, 2008, at 2:00 PM, Bill Burke wrote: > >> After talking on the mail list a few weeks ago about ContextResolver (I >> didn't know WTF it was for), I found that it exists solely to provide >> pluggable JAXB contexts in the RI. I figure, since its there, we might >> as well use it instead of JAXBCache. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Ryan J. M. <ry...@da...> - 2008-08-01 21:21:53
|
Ah! Now it all make more sense. This might be a better approach than additional annotations. Quick question though: do we support discovery of ContextResolver instances annotated with @Provider, or do we have to register them manually? And if it's manually, where does one do that in RESTEasy? I was poking around, but got lost :) Ryan- On Jul 31, 2008, at 2:00 PM, Bill Burke wrote: > After talking on the mail list a few weeks ago about ContextResolver > (I > didn't know WTF it was for), I found that it exists solely to provide > pluggable JAXB contexts in the RI. I figure, since its there, we > might > as well use it instead of JAXBCache. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2008-08-01 19:40:38
|
FYI. Next release late August should be up to 0.10 compliance. -------- Original Message -------- Subject: Proposed Final Draft posted Date: Fri, 01 Aug 2008 15:21:36 -0400 From: Marc Hadley <Mar...@Su...> Reply-To: us...@js... To: de...@js..., us...@js... I just posted the JCP proposed final draft and corresponding 0.10 API: Spec: https://jsr311.dev.java.net/drafts/spec20080801.pdf Javadoc: https://jsr311.dev.java.net/nonav/releases/0.10/index.html SVN tag: https://jsr311.dev.java.net/source/browse/jsr311/tags/jsr311-api-0.10/ I've submitted the spec and javadoc to the JCP so our JCP page should be updated with the new milestone in due course. Once that happens I'll switch the spec link on the java.net page to point to the JCP download for consistency. Next step is final release which is planned for end of September. In the meantime we'll be focussing on bringing the RI (Jersey) into full compliance and on TCK coverage. I'm taking vacation next week, I'll be back online Aug 11th. Marc. --- Marc Hadley <marc.hadley at sun.com> CTO Office, Sun Microsystems. --------------------------------------------------------------------- To unsubscribe, e-mail: use...@js... For additional commands, e-mail: use...@js... -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Ryan J. M. <ry...@da...> - 2008-08-01 11:09:07
|
Ideally to have all of this stuff done, it'd realistically be somewhere between 8/8 to 8/12. I won't have much time this weekend to get at it. Ryan- On Jul 31, 2008, at 1:59 PM, Bill Burke wrote: > Any idea when you're going to be done? I want to do a release soon. > > Ryan McDonough wrote: >> Bill, >> I do have more plans for this and had started work on a few >> annotations to allow you to do the following: >> * pass multiple package names to the JAXBContext >> * provide a schema to validate against >> Are there any other configuration options you can think of that >> would be required? There's one minor undocumented fetaure that the >> marshaller has: if you pass an X-Xml-Formatted header to true, the >> marshaller will format the output. >> And yes, I do have plans to update the JSON providers as well ;) >> Ryan- >> On Thu, Jul 31, 2008 at 12:42 PM, Bill Burke <bb...@re... <mailto:bb...@re... >> >> wrote: >> I don't see a way to configure JAXB at all anymore with Ryan's >> changes. >> Do we need it more configurable on a per Class/JAXBContext basis? >> Thanks >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com <http://bill.burkecentral.com/> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in >> the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> <http://moblin-contest.org/redirect.php?banner_id=100&url=/> >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> <mailto:Res...@li...> >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers >> -- >> Ryan J. McDonough >> http://www.damnhandy.com > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com |
|
From: Bill B. <bb...@re...> - 2008-08-01 02:18:08
|
I'm going to rewrite the @FormValues functionality that Ryan added.
These will be the changes:
* @FormValues renamed to @Form
* org.jboss.resteasy.annotations.FormParam is redundant, spec now has a
@FormParam annotation
* @Form will only be a parameter, method, field annotation and used like
any other @*Param annotation.
* There will be no provider for it, instead it will be its own
ParameterInjector
* You can use any @*Param annotation within the @Form class you are
injecting on any setter method, field, or constructor param of that class.
* I'll add a new @Body annotation that allows you to inject a message
body into a property of the form class.
Here's an example:
public class MyForm {
@FormParam("foo")
int foo;
@HeaderParam("myHeader")
public void setMyHeader(double val) {...}
public MyForm(@Context Request request) {...}
}
@Path("/")
public class MyResource
{
@POST
public void post(@Form MyForm form) {...}
}
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|