[javaee-spec users] Re: default resources

From: Bill Shannon <>
Date: Mon, 17 Nov 2014 13:56:18 -0800

Romain Manni-Bucau wrote on 11/17/14 13:05:
> 2014-11-17 21:55 GMT+01:00 Bill Shannon <>:
>> Romain Manni-Bucau wrote on 11/17/14 12:39:
>>> 2014-11-17 21:30 GMT+01:00 Bill Shannon <>:
>>>> Romain Manni-Bucau wrote on 11/17/14 12:22:
>>>>> 2014-11-17 21:02 GMT+01:00 Bill Shannon <>:
>>>>>> Romain Manni-Bucau wrote on 11/15/14 03:01:
>>>>>>> 2014-11-14 22:54 GMT+01:00 Bill Shannon <>:
>>>>>>>> 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.