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.