Sure, will do, right now I am using an entirely separate project.
Paul Sandoz wrote:
> On Sep 25, 2007, at 9:47 PM, Doug Kohlert wrote:
>
>> Great, that is what I will do.
>> Thanks
>>
>
> Could you create a branch and do your development work in that branch?
> that way we don't loose any code, it is more visible to project
> members, and it does not affect the trunk and future releases if the
> feature is not ready in time for the next release.
>
>
>> Marc Hadley wrote:
>>> On Sep 25, 2007, at 2:35 PM, Doug Kohlert wrote:
>>>> I am working on a Resource model that can be used at tool time and
>>>> runtime to model a resource.
>>>> How tightly coupled should I make this to the jersey classes? For
>>>> example, should I be storing
>>>> a String[] or a MediaTypeList?
>>>
>>> We may want to add the Resource model to the JSR 311 API so we can
>>> support annotation-challenged environments. With that in mind I
>>> think you should steer clear of internal Jersey classes where
>>> possible but feel free to use any JSR 311 classes/interfaces. E.g.
>>> the above could be MediaType[] or List<MediaType> but not
>>> MediaTypeList.
>>>
>
> Just to be clear the abstract resource class model API/SPI should
> depend on the JAX-RS API and not the Jersey API or the internal
> classes. If you need something that is not currently in the JAX-RS API
> we can consider adding it.
>
> It is very important to validate the media types and MediaType will do
> that, and returning List<MediaType> is a very useful. Same goes for
> URI templates, we can return String but validate using the
> UriTemplateType. However, it would be nice to consider such a type as
> part of the API.
>
> So for the implementation i think it OK to use Jersey specific
> classes. Note that in the implementation the Produce/ConsumeMime list
> are ordered as specified by JSR-311 and it would be useful to retain
> that order in the model. Further more Produce/ConsumeMime are likely
> to support an optional q parameter in the future to sort the media
> types in terms of priority. There is internal stuff in Jersey that you
> can use to order instances of MediaType.
>
> Also note that the HTTP methods that don't have a produce/consumeMime
> inherit those (if present) on the declaring class (i cannot recall if
> these annotations are inherited or not...), so effectively it is not
> required to query for produce/consume on the class and we only require
> such things associated with HTTP methods (sub-methods or otherwise).
>
> If there is no produce/consume internally i default to "*/*" so it
> might be useful for the model to do the same?
>
> Paul.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>