[Bug 65240] Multi line CATALINA_OPTS is failing in with new catalina.sh

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65240

Maciej Jaros  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #2 from Maciej Jaros  ---
Interesting case... Never had problem with stars in options. I guess because we
keep application options in a properties file (and just point to the properties
file).

Use case for multiline is quite simple really -- readability, editing and
cleaner diffs. I would be surprised if it's not a common way of doing that.

We have quite a lot of that so that so more like this on a devel machine:
```
-DmolnetConfigLocation=file:$CATALINA_BASE/conf/app.properties
-Dspring.profiles.active=.
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=.
-Dcom.sun.management.jmxremote.ssl=.
-Dcom.sun.management.jmxremote.authenticate=.
-Dcom.sun.management.jmxremote.local.only=.
-Djava.rmi.server.hostname=.
-Dfile.encoding=.
-agentlib:jdwp=.
```
Nice and easy to ready, change, copy. Great for diffs in git.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65244] annotations from @HandlesTypes are checked only at class level when scanning

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65244

--- Comment #6 from romain.manni-bucau  ---
If it helps:

1. TomEE already does it and cost of reading the full class can be limited by
adjusting well the buffer size
2. Never use a real use case for "not class" level and worse cases frameworks
can add a @MarkClass
3. Maybe something to clarify at spec level before changing in tomcat since it
will break app (clazz.getAnnotation(MyMarker.class).value() == NPE if changed)?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

buildbot success in on tomcat-85-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-85-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-85-trunk/builds/2692

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-85-commit' 
triggered this build
Build Source Stamp: [branch 8.5.x] 71682811e52ea6f0413ee7300f1234ac99700026
Blamelist: Mark Thomas 

Build succeeded!

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JSTL issue

[Christopher Schultz]

Mark,

On 4/15/21 04:57, Mark Thomas wrote:
If we wanted to address this and provide a way to allow JSTL to have the 
control over the included content required to pass this TCK test then we 
could modify 'useBomIfPresent' as follows:


- true   - no change - remains the default

- false  - no change

- ignore - as current false but does not strip the BoM from the output


I might re-name the "ignore" case to "pass-through" to be perfectly 
clear about what's happening. "Ignore" might be mis-interpreted to mean 
that the BOM would be removed. "Pass-through" makes it clear that the 
BOM will still be sent IMHO.


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 8.5.x updated: Limit local LDAP server to listening on localhost

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 7168281  Limit local LDAP server to listening on localhost
7168281 is described below

commit 71682811e52ea6f0413ee7300f1234ac99700026
Author: Mark Thomas 
AuthorDate: Thu Apr 15 16:48:50 2021 +0100

Limit local LDAP server to listening on localhost
---
 test/org/apache/catalina/realm/TestJNDIRealmIntegration.java | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/test/org/apache/catalina/realm/TestJNDIRealmIntegration.java 
b/test/org/apache/catalina/realm/TestJNDIRealmIntegration.java
index cd69267..e52d7c2 100644
--- a/test/org/apache/catalina/realm/TestJNDIRealmIntegration.java
+++ b/test/org/apache/catalina/realm/TestJNDIRealmIntegration.java
@@ -16,6 +16,7 @@
  */
 package org.apache.catalina.realm;
 
+import java.net.InetAddress;
 import java.util.ArrayList;
 import java.util.Arrays;
 import java.util.Collection;
@@ -35,6 +36,7 @@ import org.apache.juli.logging.LogFactory;
 
 import com.unboundid.ldap.listener.InMemoryDirectoryServer;
 import com.unboundid.ldap.listener.InMemoryDirectoryServerConfig;
+import com.unboundid.ldap.listener.InMemoryListenerConfig;
 import com.unboundid.ldap.sdk.AddRequest;
 import com.unboundid.ldap.sdk.LDAPConnection;
 import com.unboundid.ldap.sdk.LDAPResult;
@@ -130,6 +132,10 @@ public class TestJNDIRealmIntegration {
 @BeforeClass
 public static void createLDAP() throws Exception {
 InMemoryDirectoryServerConfig config = new 
InMemoryDirectoryServerConfig("dc=example,dc=com");
+InetAddress localhost = InetAddress.getByName("localhost");
+InMemoryListenerConfig listenerConfig =
+new InMemoryListenerConfig("localListener", localhost, 0, 
null, null, null);
+config.setListenerConfigs(listenerConfig);
 config.addAdditionalBindCredentials("cn=admin", "password");
 ldapServer = new InMemoryDirectoryServer(config);
 

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 9.0.x updated (0fc9226 -> 012d0d6)

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from 0fc9226  Add unboundid.jar to test class path so new tests can compile
 add 012d0d6  Limit local LDAP server to listening on localhost

No new revisions were added by this update.

Summary of changes:
 test/org/apache/catalina/realm/TestJNDIRealmIntegration.java | 6 ++
 1 file changed, 6 insertions(+)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Limit local LDAP server to listening on localhost

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 6e0aa41  Limit local LDAP server to listening on localhost
6e0aa41 is described below

commit 6e0aa416353fef0ea932d3d79f1c474bfad7
Author: Mark Thomas 
AuthorDate: Thu Apr 15 16:48:50 2021 +0100

Limit local LDAP server to listening on localhost
---
 test/org/apache/catalina/realm/TestJNDIRealmIntegration.java | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/test/org/apache/catalina/realm/TestJNDIRealmIntegration.java 
b/test/org/apache/catalina/realm/TestJNDIRealmIntegration.java
index cd69267..e52d7c2 100644
--- a/test/org/apache/catalina/realm/TestJNDIRealmIntegration.java
+++ b/test/org/apache/catalina/realm/TestJNDIRealmIntegration.java
@@ -16,6 +16,7 @@
  */
 package org.apache.catalina.realm;
 
+import java.net.InetAddress;
 import java.util.ArrayList;
 import java.util.Arrays;
 import java.util.Collection;
@@ -35,6 +36,7 @@ import org.apache.juli.logging.LogFactory;
 
 import com.unboundid.ldap.listener.InMemoryDirectoryServer;
 import com.unboundid.ldap.listener.InMemoryDirectoryServerConfig;
+import com.unboundid.ldap.listener.InMemoryListenerConfig;
 import com.unboundid.ldap.sdk.AddRequest;
 import com.unboundid.ldap.sdk.LDAPConnection;
 import com.unboundid.ldap.sdk.LDAPResult;
@@ -130,6 +132,10 @@ public class TestJNDIRealmIntegration {
 @BeforeClass
 public static void createLDAP() throws Exception {
 InMemoryDirectoryServerConfig config = new 
InMemoryDirectoryServerConfig("dc=example,dc=com");
+InetAddress localhost = InetAddress.getByName("localhost");
+InMemoryListenerConfig listenerConfig =
+new InMemoryListenerConfig("localListener", localhost, 0, 
null, null, null);
+config.setListenerConfigs(listenerConfig);
 config.addAdditionalBindCredentials("cn=admin", "password");
 ldapServer = new InMemoryDirectoryServer(config);
 

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65244] annotations from @HandlesTypes are checked only at class level when scanning

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65244

--- Comment #4 from romain.manni-bucau  ---
Hi,

Not sure it changed in last release but since javaee 6 (to at least EE8) it was
only about types:
https://docs.oracle.com/javaee/6/api/javax/servlet/annotation/HandlesTypes.html:

> Set of application classes that extend, implement, or have been annotated 
> with the class types listed

Seems it means "the type is annotated" and not "one of its member".

So it excludes fields and methods AFAIK.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65244] annotations from @HandlesTypes are checked only at class level when scanning

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65244

--- Comment #3 from Remy Maucherat  ---
(In reply to Mark Thomas from comment #1)
> Looks like a Tomcat bug to me. That no-one has hit this bug in the 10+ years
> since the first Tomcat 7 release (where support for this was first added)
> suggests it is a very rarely used feature but we should still aim to fix it.

I would also think it would be in the spirit of HandlesTypes to do field and
method annotations since it's a way for frameworks to say "gimme anything that
has my annotation".

This is not implemented at the moment for fields or methods since:
-
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/startup/ContextConfig.java#L2429
only gets the annotations on the class
-
https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/bcel/classfile/ClassParser.java#L232
does not read any field or methods attributes including the annotations
Doing it would probably make scanning a bit slower, and would require expanding
this stuff.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JSTL issue

[Jean-Louis MONTEIRO]

Hi,

I definitely value the feedback and thoughts.

I understand and I agree it's unlikely to be a real world use case.
I am happy to give it a try to improve the flag and submit a PR for it.

I'll make sure to fire a new TCK build with everything (servlet, jsp, etc)
so we have more confidence in the fix.

Thanks

Le jeu. 15 avr. 2021 à 10:57, Mark Thomas  a écrit :

> On 15/04/2021 09:03, Jean-Louis MONTEIRO wrote:
> > I've got an answer from JSTL team.
> > Here it is
>
> 
>
> >> 1. Jakarta Tags Specification Section 7.4 details the 
> tag:
> >> c:import
> >> <
> https://github.com/eclipse-ee4j/jstl-api/blob/master/spec/src/main/asciidoc/jakarta-stl.adoc#74-cimport
> >
> >>
> >> Within this, it details the following: Character Encoding : The
> >>  for import-encoded.txt does not include an encoding so the
> >> default encoding is used: ISO-8859-1
>
> 
>
> >> At this point from a Jakarta Tags perspective, I believe the golden file
> >> is correct.
>
> Thanks for passing that on.
>
> The Default Servlet improvements were written from the perspective of
> including static content with a variety of encodings where the correct
> encoding was not always known (or maintaining an accurate mapping of
> encoding to resource would impose a significant overhead).
>
> JSTL is coming from the perspective that the encoding of the included
> target is always known.
>
> Currently Tomcat provides the 'useBomIfPresent' option to control the
> BoM handling. The current values are:
>
> - true  - BoM is stripped if present and any BoM found used to determine
>the encoding used to read the resource. This is the default.
>
> - false - BoM is stripped and resource is read using the configured file
>encoding (which will be the platform default if not explicitly
>configured)
>
> If we wanted to address this and provide a way to allow JSTL to have the
> control over the included content required to pass this TCK test then we
> could modify 'useBomIfPresent' as follows:
>
> - true   - no change - remains the default
>
> - false  - no change
>
> - ignore - as current false but does not strip the BoM from the output
>
> This would have no impact on existing users but using the new ignore
> option would allow the JSTL TCK to pass.
>
> I do wonder if this use case has any real world consequences. For that
> to be that case there would need to be an application where:
> - JSTL was importing static resources
> - the content of static resource started with the same bytes as a valid
>BoM
>
> That seems unlikely as the BoM values look to have been chosen to avoid
> this. While it is (very?) unlikely, it isn't impossible so I'm not
> against this change. Normally, I'd worry about regressions but the test
> case coverage is good in this area.
>
> Any objections to implementing this? Thoughts on a better solution?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

[Bug 65244] annotations from @HandlesTypes are checked only at class level when scanning

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65244

--- Comment #2 from Grzegorz Grzybek  ---
I don't think TCK tests this - otherwise it'd be caught.
In my personal opinion, annotations from @HandlesTypes should be checked only
at class level, not at the method level.

On the other hand, "8.1 Annotations and pluggability" mentions annotations like
@javax.annotation.PreDestroy, which suggests deep scanning.

However Tomcat (org.apache.catalina.startup.ContextConfig#processClass())
checks only 3 class-level annotations: @WebServlet, @WebFilter and @WebListener
(which are the only MUST-be-supported annotations).

Personally, I would rather change the specification than Tomcat (and
potentially Jetty and other containers) and TCK ;)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65244] annotations from @HandlesTypes are checked only at class level when scanning

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65244

--- Comment #1 from Mark Thomas  ---
Looks like a Tomcat bug to me. That no-one has hit this bug in the 10+ years
since the first Tomcat 7 release (where support for this was first added)
suggests it is a very rarely used feature but we should still aim to fix it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JSTL issue

[Mark Thomas]

On 15/04/2021 09:03, Jean-Louis MONTEIRO wrote:

I've got an answer from JSTL team.
Here it is





1. Jakarta Tags Specification Section 7.4 details the  tag:
c:import



Within this, it details the following: Character Encoding : The
 for import-encoded.txt does not include an encoding so the
default encoding is used: ISO-8859-1





At this point from a Jakarta Tags perspective, I believe the golden file
is correct.


Thanks for passing that on.

The Default Servlet improvements were written from the perspective of 
including static content with a variety of encodings where the correct 
encoding was not always known (or maintaining an accurate mapping of 
encoding to resource would impose a significant overhead).


JSTL is coming from the perspective that the encoding of the included 
target is always known.


Currently Tomcat provides the 'useBomIfPresent' option to control the 
BoM handling. The current values are:


- true  - BoM is stripped if present and any BoM found used to determine
  the encoding used to read the resource. This is the default.

- false - BoM is stripped and resource is read using the configured file
  encoding (which will be the platform default if not explicitly
  configured)

If we wanted to address this and provide a way to allow JSTL to have the 
control over the included content required to pass this TCK test then we 
could modify 'useBomIfPresent' as follows:


- true   - no change - remains the default

- false  - no change

- ignore - as current false but does not strip the BoM from the output

This would have no impact on existing users but using the new ignore 
option would allow the JSTL TCK to pass.


I do wonder if this use case has any real world consequences. For that 
to be that case there would need to be an application where:

- JSTL was importing static resources
- the content of static resource started with the same bytes as a valid
  BoM

That seems unlikely as the BoM values look to have been chosen to avoid 
this. While it is (very?) unlikely, it isn't impossible so I'm not 
against this change. Normally, I'd worry about regressions but the test 
case coverage is good in this area.


Any objections to implementing this? Thoughts on a better solution?

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65244] annotations from @HandlesTypes are checked only at class level when scanning

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65244

Grzegorz Grzybek  changed:

   What|Removed |Added

 CC||gr.grzy...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65244] New: annotations from @HandlesTypes are checked only at class level when scanning

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65244

Bug ID: 65244
   Summary: annotations from @HandlesTypes are checked only at
class level when scanning
   Product: Tomcat 9
   Version: 9.0.45
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet
  Assignee: dev@tomcat.apache.org
  Reporter: gr.grzy...@gmail.com
  Target Milestone: -

I have a test WAR, where one of the detected SCIs has this @HandlesTypes (for
testing purpose only):

@HandlesTypes({ Deprecated.class })

Then, in the same WAR, I have a servlet with this dummy field:

@Deprecated
public Object dummy;

`org.apache.tomcat.util.bcel.classfile.JavaClass#getAnnotationEntries()`
returns null for this servlet class inside
`org.apache.catalina.startup.ContextConfig#checkHandlesTypes()`

I know it's artificial and I (later, after scanning) get a list of these
classes passed to SCI:

{org.ops4j.pax.web.samples.war.scis.SCIFromTheWab1@2927}  ->
{java.util.HashSet@3017}  size = 9
 key: org.ops4j.pax.web.samples.war.scis.SCIFromTheWab1  =
{org.ops4j.pax.web.samples.war.scis.SCIFromTheWab1@2927} 
 value: java.util.HashSet  = {java.util.HashSet@3017}  size = 9
  0 = {@3023} "class javax.faces.component.UIViewRoot$ViewScope"
  1 = {@3024} "class org.apache.myfaces.view.facelets.tag.jsf.ComponentHandler"
  2 = {@3025} "class org.apache.myfaces.view.facelets.tag.jsf.ConvertHandler"
  3 = {@3026} "class javax.faces.view.facelets.ResourceResolver"
  4 = {@3027} "class org.apache.myfaces.application.StateCacheFactory"
  5 = {@3028} "class org.apache.myfaces.shared.taglib.UIComponentTagUtils"
  6 = {@3029} "interface javax.faces.bean.package-info"
  7 = {@3030} "class org.apache.myfaces.view.facelets.tag.jsf.ValidateHandler"
  8 = {@3031} "class org.apache.myfaces.view.facelets.tag.MetaRule"

Each of the classes are annotated with @Deprecated.

The problem (?) I found is that chapter "8.2.4 Shared libraries / runtimes
pluggability" of Servlet 4 specification says:

> In addition to the ServletContainerInitializer we also have an annotation -
HandlesTypes. The HandlesTypes annotation on the implementation of the
ServletContainerInitializer is used to express interest in classes that may
have annotations ___(type, method or field level annotations)___ specified in
the value of
the HandlesTypes or if it extends / implements one those classes anywhere in
the
class’ super types.

So either something's wrong in Tomcat, in TCK, or Servlet spec is too
permissive...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JSTL issue

[Jean-Louis MONTEIRO]

I've got an answer from JSTL team.
Here it is

Here is my take:
>
>1. Jakarta Tags Specification Section 7.4 details the  tag:
>c:import
>
> 
>
> Within this, it details the following: Character Encoding : The
>  for import-encoded.txt does not include an encoding so the
> default encoding is used: ISO-8859-1
>
>1. If I were to do the following: charEncoding="UTF-16"/> then we would not see the BOM since the proper
>encoding is used and would see the actual text in the file rather than
>garbled characters which is what the test is actually looking for, see
>below.
>
> This test is just checking the following:
>
> <%-- If encoding is not specified, and no encoding is specified in the
>  response of the imported resource, the default of ISO-8859-1
>  will be used. --%>
>
> As to whether or not to strip the BOM when the content type of the file
> uses a BOM and the content type being used does not use a BOM I disagree
> that it should be removed, and here is why:
>
>-
>
>The encoding defaults to ISO-8859-1 which as far as I know doesn't use
>the BOM so just including the text as is in the  seems
>reasonable to me.
>-
>
>Tomcat remove the BOM from the file even when the ISO-8859-1 encoding
>is used to read the UTF-16 encoded text which I don't see how that
>improves anything. It sounds like this is stripped outside of any Jakarta
>Tags or Jakarta Pages specification and is done as a specific change to
>Tomcat since Tomcat last was executed against the TCK.
>
> At this point from a Jakarta Tags perspective, I believe the golden file
> is correct.
>





Le mer. 14 avr. 2021 à 10:16, Jean-Louis MONTEIRO  a
écrit :

> Thanks for the answer.
>
> Do you mind adding the comment in the issue?
> I can copy/paste if not. It's just to give context to others
>
> Thanks
>
> Le mar. 13 avr. 2021 à 21:44, Mark Thomas  a écrit :
>
>> On 13/04/2021 20:17, Jean-Louis MONTEIRO wrote:
>> > Hi guys,
>> >
>> > I have one JSTL issue and I'd need your feedback on it.
>> > https://github.com/eclipse-ee4j/jstl-api/issues/140
>> >
>> > Can you guys have a look and let me know what you think?
>>
>> That looks like a side-effect of the various improvements we made to the
>> Default Servlet to do a better job of including content with a variety
>> of (potentially incompatible) encodings.
>>
>> Generally, I'd expect the BoM to be skipped.
>>
>> Historically, Tomcat didn't skip the BoM, so the original golden file
>> was generated on that basis.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
> --
> Jean-Louis
>


-- 
Jean-Louis