With ResourceResolver#create/remove we throw
UnsupportedOperationException and PersistenceException.
The first one if the underlying resource provider does not allow
resource modifications, the second if anything goes wrong.
Although there is a slight difference in the reason, I'm wondering if
we need to distinguish here and just throw PersistenceException in
both cases?

WDYT?

Regards
Carsten

2012/7/30 Carsten Ziegeler <[email protected]>:
> 2012/7/30 Felix Meschberger <[email protected]>:
>> Hi,
>>
>> Am 30.07.2012 um 13:33 schrieb Carsten Ziegeler:
>>
>>> 2012/7/30 Carsten Ziegeler <[email protected]>:
>>>
>>>>
>>>>>    - A service property should be added (String or String[]) indicating
>>>>>        the query languages supported by the service. For
>>>>>        ResourceProviderFactory provided QueriableResourceProvider
>>>>>        instances this property must be defined on the
>>>>>        ResourceProviderFactory service.
>>>> Agreed.
>>>>
>>> While I first thought this service prop is a good idea, I'm wondering
>>> if we need it at all. As the QRP will return null if the language is
>>> not provided, the property is not really needed
>>
>> Its not needed. Its purely for informational purposes (and could be used for 
>> logging and web console).
>>
>> Or we define the methods to throw an exception if an unsupported language is 
>> used in which case the ResourceResolver could check against this list before 
>> actually calling the ResourceProvider.
>
> Yes, I think we should go the latter way - resource resolver checks
> the prop and only calls the QRP if the language is declared in the
> prop.
>
> Otherwise the prop and the implementation could go out of sync - and
> as a bonus it would allow to disable some language on a QRP (not sure
> about a use case for this but anyway)
>
> Carsten
>>
>> Regards
>> Felix
>>
>>>
>>> WDYT?
>>>
>>> Carsten
>>>
>>>> I'll clarify the javadocs and add the prop.
>>>>
>>>> Thanks
>>>> Carsten
>>>>>
>>>>> WDYT ?
>>>>>
>>>>> Regards
>>>>> Felix
>>>>
>>>>
>>>>
>>>> --
>>>> Carsten Ziegeler
>>>> [email protected]
>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> [email protected]
>>
>
>
>
> --
> Carsten Ziegeler
> [email protected]



-- 
Carsten Ziegeler
[email protected]

Reply via email to