On 23/05/2021 22:40, Steve Storey wrote:
<snip/>
The spec at
https://docs.oracle.com/javaee/7/api/javax/el/ExpressionFactory.html#newInstance--
says:
Use the Services API (as detailed in the JAR specification).
The above is the key part.
If a
resource with the name of META-INF/services/javax.el.ExpressionFactory
exists, then its first line, if present, is used as the UTF-8 encoded name
of the implementation class.
The above is a (very) inaccurate summary of the Services API. I'll get
that sentence removed from the API Javadoc shortly.
but the tomcat-embed-el.jar file (as of 9.0.31 - "Add a META-INF/services
entry to jasper-el.jar so that the Expression Language implementation can
be discovered via the services API. (markt)") has the following file
content:
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
org.apache.el.ExpressionFactoryImpl
and thus having the licence header violates the spec.
No it doesn't. Please read the Services API specification.
When the class loader
situation means that a non-Tomcat javax.el.ExpressionFactory is resolving
which implementation to use (which happens in Wildfly but judging by
Google, also several other app servers), then it fails with a trace with
the following sort of root cause:
Caused by: java.lang.ClassNotFoundException: # Licensed to the Apache
Software Foundation (ASF) under one or more from [Module
"deployment.services-boot.war" from Service Module Loader]
Then you need to raise a bug for any application server that behaves
this way as it is not following the Services API specification.
In this specific case, it's the JBoss spec implementation at
https://github.com/jboss/jboss-jakarta-el-api_spec/blob/master/api/src/main/java/org/jboss/el/cache/FactoryFinderCache.java#L99
which reads the first line only,
Then you need to raise a bug with JBoss.
but the RI also does the same:
https://github.com/javaee/el-spec/blob/master/api/src/main/java/javax/el/FactoryFinder.java#L154
That is not the current reference implementation. The current reference
implementation is:
https://github.com/eclipse-ee4j/el-ri/blob/master/api/src/main/java/jakarta/el/FactoryFinder.java#L93
If you review the history for that file you'll find this:
https://github.com/eclipse-ee4j/el-ri/issues/118
and this:
https://github.com/eclipse-ee4j/el-ri/commit/6075bc9
so it's the Tomcat ExpressionFactory that appears to be more tolerant than
the specification allows rather than the others being buggy?
Nope. Tomcat is specification compliant and the others are buggy.
Assuming you agree that it's a spec violation,
I (speaking for the Tomcat developers on this point) do not agree.
do I raise a bugzilla myself or does one of the Tomcat developers?
In this case, neither. You need to raise a bug with JBoss and any other
app server where you have observed this behaviour.
Would an acceptable solution be to
simply move the licence header to be _after_ the first line ?
No. The acceptable solution is for the buggy app servers to fix their EL
implementation.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
