2014-11-17 21:30 GMT+01:00 Bill Shannon <bill.shannon_at_oracle.com>:
> Romain Manni-Bucau wrote on 11/17/14 12:22:
>> 2014-11-17 21:02 GMT+01:00 Bill Shannon <bill.shannon_at_oracle.com>:
>>> Romain Manni-Bucau wrote on 11/15/14 03:01:
>>>> 2014-11-14 22:54 GMT+01:00 Bill Shannon <bill.shannon_at_oracle.com>:
>>>>> This discussion seems to have wandered off topic...
>>>>>
>>>>> I'm not trying to raise the question of whether default resources are a good
>>>>> idea or not. We've already decided they are, and they're already in the spec.
>>>>> You might disagree with that decision, but that decision has already been made.
>>>>>
>>>>
>>>> Yes, sorry but mainly wanted to make more obvious default resources
>>>> are not defined enough today and that some more work on this topic
>>>> would be very welcomed.
>>>
>>> I'm not sure in what sense you think they're not defined well enough,
>>> although it may depend on whether you think (e.g.) the JDBC, JPA, and
>>> JMS specs are defined well enough to allow you to write a portable
>>> application that's independent of the implementation of that spec.
>>>
>>
>> For JMS: you don't know if you are local/remote/protocol. For DS: you
>> don't know if you are in memory, on disk (and where), remote.... All I
>> ask is to add a line saying use cases associated with theses default
>> resources (1000 datasource lines? 1000000?... for instance).
>
> Sorry, I don't understand what you want added where.
>
You know you have a car but you don't know if you can go in city, road
or highway. That's current state.
>>>>> Given that we made that decision, and given that we believe it is a useful and
>>>>> usable feature appropriate for some users and some use cases, how should we
>>>>> deal with the issue raised in my original message?
>>>>
>>>> Maybe I didn't get it right but your message is mainly about product
>>>> specific features in which case vendors should handle it and not the
>>>> spec since features are already out the spec. Said otherwise if the
>>>> spec allows to influence vendors features then this should be spec
>>>> features. Having auto-adjusting resources or default resources is
>>>> mainly the same in term of behavior so not sure spec should go further
>>>> regading it.
>>>
>>> It may help to better understand how our Java Compatibility rules work...
>>>
>>> When the spec says "X happens", it means "X *always* happens", not
>>> "X happens unless the product overrides it" or "X happens if you're in
>>> Java EE compatibility mode" or "X happens unless you select option Y".
>>>
>>> That means products *always* have to map resource references to default
>>> resources, as described in the spec. Always. No matter what. You can't
>>> have a product-specific feature that does something different.
>>>
>>
>> Which is not true. A vendor can (of course) override EE rules if
>> needed/asked. Think all impls do it.
>
> The Java EE Compatibility rules prohibit that. It's true that they can,
> but they're not allowed to. Just because you *can* exceed the speed limit
> doesn't mean it's *legal* to do so.
Even if default is respected?