Romain Manni-Bucau wrote on 11/17/14 13:05:
> 2014-11-17 21:55 GMT+01:00 Bill Shannon <bill.shannon_at_oracle.com>:
>> Romain Manni-Bucau wrote on 11/17/14 12:39:
>>> 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.
>>
>> We've tried to explicitly stay away from "quality of service" specifications.
>> It becomes too much of a judgment call instead of a testable assertion.
>> In the end, users need to choose a runtime/product that meets their
>> reliability/scalability/performance/whatever requirements and it seems
>> unlikely we'll ever be able to encode all those requirements in an
>> application package.
>>
>
> Fully agree but when it comes to resources that's almost the only
> thing you care about. That's why i said it was awesome for tests but
> not usable in prod environments.
I think we may disagree on the use cases for which the default resources
are usable with no additional quality of service information.
>>>>>>>> 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?
>>
>> Yes, even if.
>>
>> The spec doesn't say "here's what you have to do by default".
>> The spec says "here's what you have to do". Period. End of sentence.
>> No qualifiers. If you ever want to do something different, the spec
>> has to explicitly allow it.
>>
>
> If that's not activated by default and user activates it by itself
> then the spec is no more in action so I don't see why it is an issue.
> If that's the case it should be broken with next spec cause if
> something in the spec N prevents an app to work and it can't be
> changed even with proprietary config/code then you just don't care
> about some users until spec N+1 at least.
Which is why several of my options suggest that we consider this a bug
in the current spec and fix it there.
> In practise no issues: there is not a single (open source at least)
> library doing what you describe. All are customizable enough to
> completely violate EE if we want - I don't say it should be done just
> flexibility is good and natural since most of products are usable with
> EE alternatives.
What matters most to us is products that claim to be Java EE compatible
and use the "Java Compatible, Enterprise Edition" logo.