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).
>>> 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.
> And that's where the conflict comes in, which is why I raised this issue.