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.
>>>> 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.