Let me clarify that, a separate project on my local machine, not java.net.
Doug Kohlert wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>