Menu
▾
▴
resteasy-developers — The main list for RESTEasy developers to discuss project development
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: Solomon D. <sd...@gm...> - 2008-11-19 02:53:14
|
I definitely don't mind making a copy. It took me a while, but I finally
got it up and running. It was mostly trying to figure out why my c:forEach
JSTL wasn't working... turned out to be a jetty version issue.
The Code changes I need to make are as follows:
1. web.xml: replace ResteasyBootrap + SpringContextLoaderListener +
HttpServletDispatcher with Spring's DispatcherServlet
(servlet-name=Resteasy).
2. rename application.xml to Resteasy-servlet.xml
3. add in <import resource="classpath:spring-webmvc.xml" /> in
Resteasy-servlet.xml
4. add a couple methods in ContactServiceImpl that return Spring's
ModelAndView. for example new
ModelAndView("/WEB-INF/contacts.jsp").addObject("allContacts",
dao.findAllContacts);
5. create the /WEB-INF/contacts.jsp.
I have that all done, but the jsp looks bad, but gets the point across.
Should I create a whole new project, or just add a 'springweb-mvc-service'
module to the current spring-hibernate-contacts project?
<rant, ignore if you want>
With that said, the purpose of any IoC engine is to the object management
process easier or at least more consistent. Using ResteasyBootrap +
SpringContextLoaderListener + HttpServletDispatcher works, but it's not as
consistent as a purely Spring managed application (which you see in #1 only
consists of Spring's DispatcherServlet rather than the 3 Resteasy classes).
There are settings in ResteasyBootrap used for managing the creation and
life cycle of objects that are not allowed with SpringContextLoaderListener.
Also, there are quite a few objects that are managed outside of spring,
namely the registry and the dispatcher which leads to some issues when you
want to do more advanced Spring configuration.
</rant>
-Solomon
On Mon, Nov 17, 2008 at 6:38 PM, Bill Burke <bb...@re...> wrote:
> Actually, I'd rather have a *copy* of the Spring example that does the
> JSP/MVC stuff. The current Spring example is simple and easy to
configure
> and no extra moving parts.
>
> Bill Burke wrote:
>>
>> today or wednesday...
>>
>> Just an example Spring MVC would be cool...We're good though. TCK work
>> starts next.
>>
>> Solomon Duskis wrote:
>>>
>>> Is beta 9 out? Will it be out soon? What else needs to be done?
>>>
>>> -Solomon
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
-------------------------------------------------------------------------
>>> 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: Stef E. <st...@ep...> - 2008-11-18 13:33:50
|
On Tue, Nov 18, 2008 at 08:11:01AM -0500, Bill Burke wrote: > What do you mean? Can you give an example? This is JSF tag documentation: http://www.jboss.org/file-access/default/members/jbossrichfaces/freezone/docs/tlddoc/index.html And it's funny but I just cannot remember where I saw those javadoc-style XML documentation. I'm pretty sure it was generated from either XSD or JAXB... What I mean is that we could have a doctlet which would collect all resources available by path and create javadoc for each HTTP method. As a trivial example, each resource path part would look like a javadoc package, each end part a class, and each HTTP method an object method. All this would be derived from more the JAX-RS annotation than the implementation's Java structure. -- Stéphane Epardaud |
|
From: Bill B. <bb...@re...> - 2008-11-18 13:11:10
|
What do you mean? Can you give an example? Stef Epardaud wrote: > Hi, > > I was just thinking, is anyone working on generating javadoc > documentation from JAX-RS sources the way JAXB and JSR components do it? > If not perhaps we should give it a try? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Stef E. <st...@ep...> - 2008-11-18 09:57:25
|
Hi, I was just thinking, is anyone working on generating javadoc documentation from JAX-RS sources the way JAXB and JSR components do it? If not perhaps we should give it a try? -- Stéphane Epardaud |
|
From: Bill B. <bb...@re...> - 2008-11-17 23:38:31
|
Actually, I'd rather have a *copy* of the Spring example that does the JSP/MVC stuff. The current Spring example is simple and easy to configure and no extra moving parts. Bill Burke wrote: > today or wednesday... > > Just an example Spring MVC would be cool...We're good though. TCK work > starts next. > > Solomon Duskis wrote: >> Is beta 9 out? Will it be out soon? What else needs to be done? >> >> -Solomon >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> 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-11-17 17:37:04
|
Yeah sure. Solomon Duskis wrote: > Would it be ok if I updated the spring-hibernate-contacts-services > module with a JSP example? > > -Solomon > > On Mon, Nov 17, 2008 at 11:46 AM, Bill Burke <bb...@re...> wrote: >> today or wednesday... >> >> Just an example Spring MVC would be cool...We're good though. TCK work >> starts next. >> >> Solomon Duskis wrote: >>> Is beta 9 out? Will it be out soon? What else needs to be done? >>> >>> -Solomon >>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------- >>> 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 >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Solomon D. <sd...@gm...> - 2008-11-17 16:59:48
|
Would it be ok if I updated the spring-hibernate-contacts-services module with a JSP example? -Solomon On Mon, Nov 17, 2008 at 11:46 AM, Bill Burke <bb...@re...> wrote: > today or wednesday... > > Just an example Spring MVC would be cool...We're good though. TCK work > starts next. > > Solomon Duskis wrote: >> >> Is beta 9 out? Will it be out soon? What else needs to be done? >> >> -Solomon >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> 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-11-17 16:46:34
|
today or wednesday... Just an example Spring MVC would be cool...We're good though. TCK work starts next. Solomon Duskis wrote: > Is beta 9 out? Will it be out soon? What else needs to be done? > > -Solomon > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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: Solomon D. <sd...@gm...> - 2008-11-17 15:57:29
|
Is beta 9 out? Will it be out soon? What else needs to be done? -Solomon |
|
From: Christian S. <chr...@gm...> - 2008-11-14 17:20:23
|
Thanks! Works now with NO_CONTENT. 2008/11/14 Bill Burke <bb...@re...> > Well, HTTP 1.1 says that you are required to send 204, NO_CONTENT, but the > ClientFramework still has a bug there even if you do that. I just fixed it. > > Christian Sadilek wrote: > >> should mention it works if the return type on the client is >> Response.Status. So the question is should it also work with Response or >> ClientResponse<T> as return type in the client interface without manually >> setting the content type for DELETE, even if there is no response entity at >> all. It is just convenience. I would rather use ClientResponse<T> for >> methods in the client interface. >> >> Christian >> >> 2008/11/14 Christian Sadilek <chr...@gm... <mailto: >> chr...@gm...>> >> >> >> I checked out the latest version from trunk. It works now for GET, >> POST and PUT but I am still having problems with DELETE, but maybe I >> am doing something wrong. I have a method annotated with @DELETE >> that returns Response.ok().build(). The Client Framework then throws >> the following exception no matter if there are @Produce or @Consume >> annotations or not: org.jboss.resteasy.client.ClientResponseFailure: >> No Content-Type header specified >> >> Since DELETE in this case is not returning any response entity, >> should it be necessary to set a content-type at all? >> >> thanks, >> Christian >> >> 2008/11/11 Bill Burke <bb...@re... <mailto:bb...@re...>> >> >> Resteasy-144 Fixed. I should have done it earlier. >> >> Christian Sadilek wrote: >> >> >> I'd vote for >> https://jira.jboss.org/jira/browse/RESTEASY-144. I know >> there is a workaround by manually setting the content type >> but still it would be great to have that one fixed. >> >> Christian >> >> 2008/11/10 Bill Burke <bb...@re... >> <mailto:bb...@re...> <mailto:bb...@re... >> >> <mailto:bb...@re...>>> >> >> >> Anything quick you need fixed before the beta-9 release? >> Please say >> so now. >> >> >> -- >> 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=/> >> < >> 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...> >> <mailto: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: Bill B. <bb...@re...> - 2008-11-14 16:06:07
|
Well, HTTP 1.1 says that you are required to send 204, NO_CONTENT, but the ClientFramework still has a bug there even if you do that. I just fixed it. Christian Sadilek wrote: > should mention it works if the return type on the client is > Response.Status. So the question is should it also work with Response or > ClientResponse<T> as return type in the client interface without > manually setting the content type for DELETE, even if there is no > response entity at all. It is just convenience. I would rather use > ClientResponse<T> for methods in the client interface. > > Christian > > 2008/11/14 Christian Sadilek <chr...@gm... > <mailto:chr...@gm...>> > > > I checked out the latest version from trunk. It works now for GET, > POST and PUT but I am still having problems with DELETE, but maybe I > am doing something wrong. I have a method annotated with @DELETE > that returns Response.ok().build(). The Client Framework then throws > the following exception no matter if there are @Produce or @Consume > annotations or not: org.jboss.resteasy.client.ClientResponseFailure: > No Content-Type header specified > > Since DELETE in this case is not returning any response entity, > should it be necessary to set a content-type at all? > > thanks, > Christian > > 2008/11/11 Bill Burke <bb...@re... <mailto:bb...@re...>> > > Resteasy-144 Fixed. I should have done it earlier. > > Christian Sadilek wrote: > > > I'd vote for > https://jira.jboss.org/jira/browse/RESTEASY-144. I know > there is a workaround by manually setting the content type > but still it would be great to have that one fixed. > > Christian > > 2008/11/10 Bill Burke <bb...@re... > <mailto:bb...@re...> <mailto:bb...@re... > <mailto:bb...@re...>>> > > > Anything quick you need fixed before the beta-9 release? > Please say > so now. > > > -- > 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=/> > > <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...> > <mailto: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: Christian S. <chr...@gm...> - 2008-11-14 12:53:10
|
should mention it works if the return type on the client is Response.Status. So the question is should it also work with Response or ClientResponse<T> as return type in the client interface without manually setting the content type for DELETE, even if there is no response entity at all. It is just convenience. I would rather use ClientResponse<T> for methods in the client interface. Christian 2008/11/14 Christian Sadilek <chr...@gm...> > > I checked out the latest version from trunk. It works now for GET, POST and > PUT but I am still having problems with DELETE, but maybe I am doing > something wrong. I have a method annotated with @DELETE that returns > Response.ok().build(). The Client Framework then throws the following > exception no matter if there are @Produce or @Consume annotations or not: > org.jboss.resteasy.client.ClientResponseFailure: No Content-Type header > specified > > Since DELETE in this case is not returning any response entity, should it > be necessary to set a content-type at all? > > thanks, > Christian > > 2008/11/11 Bill Burke <bb...@re...> > > Resteasy-144 Fixed. I should have done it earlier. >> >> Christian Sadilek wrote: >> >>> >>> I'd vote for https://jira.jboss.org/jira/browse/RESTEASY-144. I know >>> there is a workaround by manually setting the content type but still it >>> would be great to have that one fixed. >>> >>> Christian >>> >>> 2008/11/10 Bill Burke <bb...@re... <mailto:bb...@re...>> >>> >>> Anything quick you need fixed before the beta-9 release? Please say >>> so now. >>> >>> >>> -- >>> 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 >> > > |
|
From: Christian S. <chr...@gm...> - 2008-11-14 11:53:12
|
I checked out the latest version from trunk. It works now for GET, POST and PUT but I am still having problems with DELETE, but maybe I am doing something wrong. I have a method annotated with @DELETE that returns Response.ok().build(). The Client Framework then throws the following exception no matter if there are @Produce or @Consume annotations or not: org.jboss.resteasy.client.ClientResponseFailure: No Content-Type header specified Since DELETE in this case is not returning any response entity, should it be necessary to set a content-type at all? thanks, Christian 2008/11/11 Bill Burke <bb...@re...> > Resteasy-144 Fixed. I should have done it earlier. > > Christian Sadilek wrote: > >> >> I'd vote for https://jira.jboss.org/jira/browse/RESTEASY-144. I know >> there is a workaround by manually setting the content type but still it >> would be great to have that one fixed. >> >> Christian >> >> 2008/11/10 Bill Burke <bb...@re... <mailto:bb...@re...>> >> >> Anything quick you need fixed before the beta-9 release? Please say >> so now. >> >> >> -- >> 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 > |
|
From: Bill B. <bb...@re...> - 2008-11-14 08:53:51
|
NO, i should be just grabbing \\d+ and turning it into a regexp. I'll
try it out.
Solomon Duskis wrote:
> Hi guys,
>
> @Path("{id:\\d+}") doesn't seem to work, but @Path("{id:[0-9]+}") does.
> Is that intentional?
>
> -Solomon
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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: Michael B. <mic...@gm...> - 2008-11-14 08:27:43
|
a solution could be to loop over the super classes in
ResteasyProviderFactory.addStringConverter()
currently
Type[] intfs = provider.getClass().getGenericInterfaces();
is used
getGenericInterfaces()
Returns the Types representing the interfaces directly implemented by
the class or interface represented by this object.
Michael Brackx
|
|
From: Michael B. <mic...@gm...> - 2008-11-14 08:21:53
|
i would try to solve the problem in your domain layer, not in the marshaling layer. you could use a FilteredDirectoryEntry implementing the same interface as DirectoryEntry (using a decorator pattern) Michael Brackx On Fri, Nov 14, 2008 at 12:21 AM, Mike Chack (mchack) <mc...@ci...> wrote: > Would like to see if anyone has an idea as to how to produce conditional > output. > > > > Problem: We have an application that has a directory function that returns > say a Directory Entry (DE). Users can specify privacy options on a per > property basis. So when returning the results of a directory search, the > response will depend upon who is doing the search as well as the visibility > of the properties. I can envision a number of potential solutions. > > > > 1. Custom producer. > > 2. Enhance the getters of my DE class to filter (return null on a > conditional basis). > > 3. Have an enhanced annotation such as @XmlTransient that could also take > into account a custom condition. > > > > Would like to hear if this is a pattern that anyone has thought about as > well as thoughts on the best method going forward. Should it be part of the > RestEasy Framework or is this custom enough that it really needs to be > handled on a per case basis? > > > > Thanks > > > > Mike Chack > O: +1 408.526.4639 > M: +1 408.504.6594 > mc...@ci... > > > > ------------------------------------------------------------------------- > 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: Mike C. (mchack) <mc...@ci...> - 2008-11-13 23:22:21
|
Would like to see if anyone has an idea as to how to produce conditional output. Problem: We have an application that has a directory function that returns say a Directory Entry (DE). Users can specify privacy options on a per property basis. So when returning the results of a directory search, the response will depend upon who is doing the search as well as the visibility of the properties. I can envision a number of potential solutions. 1. Custom producer. 2. Enhance the getters of my DE class to filter (return null on a conditional basis). 3. Have an enhanced annotation such as @XmlTransient that could also take into account a custom condition. Would like to hear if this is a pattern that anyone has thought about as well as thoughts on the best method going forward. Should it be part of the RestEasy Framework or is this custom enough that it really needs to be handled on a per case basis? Thanks Mike Chack O: +1 408.526.4639 M: +1 408.504.6594 mc...@ci... |
|
From: Solomon D. <sd...@gm...> - 2008-11-13 22:18:21
|
Hi guys,
@Path("{id:\\d+}") doesn't seem to work, but @Path("{id:[0-9]+}") does. Is
that intentional?
-Solomon
|
|
From: Michael B. <mic...@gm...> - 2008-11-13 19:15:21
|
some code to make it understandable
public abstract class ObjectStringConverter<T> implements StringConverter<T> {
public String toString(final T value) {
return value.toString();
}
}
public class TypeStringConverter extends ObjectStringConverter<Type>
implements StringConverter<Type> {
public Type fromString(final String value) {
return Type.fromString(value);
}
}
if TypeStringConverter does not implement StringConverter<Type>
direcly, it is not properly registered
what was asking is to allow
public class TypeStringConverter extends ObjectStringConverter<Type> {
public Type fromString(final String value) {
return Type.fromString(value);
}
}
Michael
On Thu, Nov 13, 2008 at 7:53 PM, Bill Burke <bb...@re...> wrote:
> I determine the type from the generic information
>
> public class MyConverter implements StringConverter<MyType>
>
> the implements tells Resteasy that MyConverter convertes MyType.class.
>
> Michael Brackx wrote:
>>
>> Apparently the string converter providers must implement the
>> StringConverter interface directly.
>> I was trying to use an abstract base class implementing StringConverter.
>> Could that be relaxed?
>>
>> Michael Brackx
>>
>> -------------------------------------------------------------------------
>> 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: Michael B. <mic...@gm...> - 2008-11-13 19:09:33
|
On Thu, Nov 13, 2008 at 7:55 PM, Bill Burke <bb...@re...> wrote: > Ok, but not until next release. I want to release on Monday and begin the > TCK work. No problem. I was just "thinking out loud". The problem with a DefaultValueProvider is that you can only have default value one per type. Unless you pass some (primitive) parameters with the annotation. Also, it is less clear than a constant. Michael |
|
From: Bill B. <bb...@re...> - 2008-11-13 18:55:28
|
Ok, but not until next release. I want to release on Monday and begin
the TCK work.
Michael Brackx wrote:
> @DefaultValue(DefaultPojo.class) ?
> Probably not that useful.
>
> @DefaultValue(DefaultPojoFactory.class) ?
>
> @DefaultValue(useProvider = true)
> @DefaultValue()
> and a new provider interface ?
>
> public interface DefaultValueProvider<T> {
> T get();
> }
>
> Michael Brackx
>
> On Thu, Nov 13, 2008 at 7:09 PM, Bill Burke <bb...@re...> wrote:
>>
>> Michael Brackx wrote:
>>> On Thu, Nov 13, 2008 at 6:51 PM, Bill Burke <bb...@re...> wrote:
>>>> I looked at the code and it seems that the @DefaultValue is run through
>>>> the
>>>> converter. Are you not seeing that behavior?
>>> Yes i do (actually, i added a test case for that)
>>> What i meant is not specifying the default as string, but as an object.
>>>
>>> @DefaultValue(new Pojo("default"))
>>>
>>> otherwise you would need to convert the value yourself
>>>
>>> @DefaultValue(new PojoStingConverter().toString(new Pojo("default")))
>>>
>> Both are illegal. You can only use primitive constants within annotations
>> as they are compiled directly into the bytecode.
>>
>> Bill
>>
>> --
>> 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: Bill B. <bb...@re...> - 2008-11-13 18:54:01
|
I determine the type from the generic information public class MyConverter implements StringConverter<MyType> the implements tells Resteasy that MyConverter convertes MyType.class. Michael Brackx wrote: > Apparently the string converter providers must implement the > StringConverter interface directly. > I was trying to use an abstract base class implementing StringConverter. > Could that be relaxed? > > Michael Brackx > > ------------------------------------------------------------------------- > 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: Michael B. <mic...@gm...> - 2008-11-13 18:22:16
|
@DefaultValue(DefaultPojo.class) ?
Probably not that useful.
@DefaultValue(DefaultPojoFactory.class) ?
@DefaultValue(useProvider = true)
@DefaultValue()
and a new provider interface ?
public interface DefaultValueProvider<T> {
T get();
}
Michael Brackx
On Thu, Nov 13, 2008 at 7:09 PM, Bill Burke <bb...@re...> wrote:
>
>
> Michael Brackx wrote:
>>
>> On Thu, Nov 13, 2008 at 6:51 PM, Bill Burke <bb...@re...> wrote:
>>>
>>> I looked at the code and it seems that the @DefaultValue is run through
>>> the
>>> converter. Are you not seeing that behavior?
>>
>> Yes i do (actually, i added a test case for that)
>> What i meant is not specifying the default as string, but as an object.
>>
>> @DefaultValue(new Pojo("default"))
>>
>> otherwise you would need to convert the value yourself
>>
>> @DefaultValue(new PojoStingConverter().toString(new Pojo("default")))
>>
>
> Both are illegal. You can only use primitive constants within annotations
> as they are compiled directly into the bytecode.
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
|
|
From: Bill B. <bb...@re...> - 2008-11-13 18:09:43
|
Michael Brackx wrote:
> On Thu, Nov 13, 2008 at 6:51 PM, Bill Burke <bb...@re...> wrote:
>> I looked at the code and it seems that the @DefaultValue is run through the
>> converter. Are you not seeing that behavior?
>
> Yes i do (actually, i added a test case for that)
> What i meant is not specifying the default as string, but as an object.
>
> @DefaultValue(new Pojo("default"))
>
> otherwise you would need to convert the value yourself
>
> @DefaultValue(new PojoStingConverter().toString(new Pojo("default")))
>
Both are illegal. You can only use primitive constants within
annotations as they are compiled directly into the bytecode.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Michael B. <mic...@gm...> - 2008-11-13 18:07:08
|
Apparently the string converter providers must implement the StringConverter interface directly. I was trying to use an abstract base class implementing StringConverter. Could that be relaxed? Michael Brackx |
22 messages has been excluded from this view by a project administrator.
