users@javaee-spec.java.net

[javaee-spec users] Re: default resources

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Mon, 01 Dec 2014 11:55:46 -0800

It can be difficult to determine whether a particular option or feature
actually violates the spec requirements and/or compatibility rules.
But, if you think there's a particular feature of a particular product
that might be a violation, you can report it to me (privately) and we
will investigate.

You're probably right that there are violations in some existing products.
Many of these are cases where the spec should allow more flexibility for
implementations. If we discover these, we'll update the spec accordingly.

Implementors should keep these compatibility requirements in mind as we
develop new APIs and specs to ensure the spec is written in a way that
allows the range of implementations we foresee.


Mark Struberg wrote on 11/27/14 10:56:
>> Technically, aren't all open source products in violation then?
>
> This does not only affect open source projects. I frankly know NO single EE server which does not have this tweaks here and there. And even Oracles own GlassFish and WebLogic DO have them.
> Just grab the docs and you have it.
>
>
> LieGrue,
> strub
>
>
>> On Monday, 17 November 2014, 22:01, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>> Hi,
>>
>>
>> On Mon, Nov 17, 2014 at 9:30 PM, Bill Shannon <bill.shannon_at_oracle.com>
>> wrote:
>>> 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.
>>
>> Hmmm, it's indeed true that many products have an option to change
>> some default behavior. Like the (infamous)
>> org.apache.el.parser.COERCE_TO_ZERO option, which changes an
>> unworkable (for many cases) situation.
>>
>> Portability and compatibility is one of my greatest concerns when
>> dealing with Java EE products, so I absolutely understand the need for
>> products to be as compatible as possible in the default configuration,
>> but I'm not 100% sure if changing behavior by the customer can or
>> should be forbidden.
>>
>> Technically, aren't all open source products in violation then? As I
>> can just change something in the code, recompile and have altered
>> behavior. One may argue if changing some .xml file and re-packaging a
>> product is really that different from changing a .java file and
>> recompiling.
>>
>> What I find more troublesome is that some certified Java EE servers
>> when downloaded are nothing but a JSP/Servlet container. You have to
>> explicitly edit a server.xml file to make them say a web profile
>> compatible product. Or another well known certified Java EE product
>> that out of the box doesn't honor any security settings in web.xml,
>> and only does this after fumbling with an admin web console.
>>