Re: Issues of Ahead of Time compilation support

2023-12-15 Thread Jun Suzuki 
Christopher,

2023年12月16日(土) 3:41 Christopher Schultz :
>
> Jun,
>
> On 12/15/23 08:56, Jun Suzuki wrote:
> > 2023年12月15日(金) 20:37 Rémy Maucherat :
> >>
> >> On Fri, Dec 15, 2023 at 11:54 AM Jun Suzuki  
> >> wrote:
> >>>
> >>> Rémy
> >>> Thank you so much for your support.
> >>> May I confirm a little bit further regarding your reply.
> >>>
> >>> 2023年12月15日(金) 17:08 Rémy Maucherat :
> 
>  On Fri, Dec 15, 2023 at 4:18 AM Jun Suzuki  
>  wrote:
> >>>
> > (1) Guidance is not so clear about following points:
> > Should I copy the deployed application(with or without war file?) from
> > existing Tomcat server webapps directory, to webapps directory of
> > $TOMCAT_STUFFED?
> > Should I copy all the files from conf directory of existing Tomcat
> > server, to conf directory of $TOMCAT_STUFFED?
> 
>  Yes.
>  When building your image, you have to compile all the classes into it.
>  So that means all the classes of the webapp as well. So if you don't
>  copy your webapp for the script to compile, no webapp classes ... Also
>  all the webapp Java classes and JARs will have to be included in the
>  image as well for annotation scanning.
> >>>
> >>> Is it correct that following source from existing Tomcat Server needed
> >>> to be copied into $TOMCAT_STUFFED?
> >>> A.  All files under conf folder (including war file)
> >>> B.  All files under webapps folder
> >>> C.  How about lib folder? Should it also be copied?
> >>> D.  How about java source code(which are not deployed on Tomcat)
> >>
> >> The doc is correct, so just use that:
> >> - Copy config files from conf (obvious)
> >> - Webapps go in webapps (unless the host appBase is something else)
> >> And that's it.
> >>
> 
> > (2) On the step of execution of "$JAVA_HOME/bin/java -Dcatalina.base=.
> > -Djava.util.logging.config.file=conf/logging.properties -jar
> > target/tomcat-stuffed-1.0.jar --catalina -generateCode src/main/java",
> > errors messages show as below:
> > ...
> > Can't load log handler "1catalina.org.apache.juli.AsyncFileHandler"
> > java.lang.ClassNotFoundException: 
> > 1catalina.org.apache.juli.AsyncFileHandler
> > java.lang.ClassNotFoundException: 
> > 1catalina.org.apache.juli.AsyncFileHandler
> >  at 
> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> >  at 
> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> >  at 
> > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
> > ...
> 
>  Yes, avoid the juli file handlers. There's a jul file handler I think:
>  java.util.logging.FileHandler
> >>>
> >>> I revised the source code by deleting "import java.util.*", and I
> >>> recompiled the java source and copied the war file into
> >>> $TOMCAT_STUFFED.
> >>> However, the error message remains:
> >>> Can't load log handler "1localhost.org.apache.juli.AsyncFileHandler"
> >>> java.lang.ClassNotFoundException: 
> >>> 1localhost.org.apache.juli.AsyncFileHandler
> >>> ...
> >>> Can't load log handler "2localhost.org.apache.juli.AsyncFileHandler"
> >>> java.lang.ClassNotFoundException: 
> >>> 2localhost.org.apache.juli.AsyncFileHandler
> >>
> >> Use stuff from java.util.logging instead if juli doesn't work for you.
> >> Or change the pom to add it. Juli makes things more complex with
> >> Graal, so the pom doesn't have it.
> >> As explained in the doc, the pom needs to be edited for needed 
> >> dependencies.
> >>
> >>> ...
> >>> 15-Dec-2023 10:35:47.580 INFO [main]
> >>> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
> >>> web application directory
> >>> [/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
> >>> [215] ms
> >>> 15-Dec-2023 10:35:47.580 INFO [main]
> >>> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
> >>> web application directory
> >>> [/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
> >>> [215] ms
> >>> 15-Dec-2023 10:35:47.583 INFO [main]
> >>> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> >>> ["http-nio-8080"]
> >>> 15-Dec-2023 10:35:47.583 INFO [main]
> >>> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> >>> ["http-nio-8080"]
> >>>
> >>> Since the error messages are showing as above and the process is
> >>> hanging on there, I could not proceed with the step of the next "maven
> >>> package" unless I open another terminal to run maven command.
> >>> Do you have any idea about how to fix this error?
> >>
> >> Well, there's no error there, so it's fine. The process is to generate
> >> reflection metadata for your webapp depending on what it needs, so you
> >> need to write a script that exercises all your

Re: Issues of Ahead of Time compilation support

2023-12-15 Thread Christopher Schultz 

Jun,

On 12/15/23 08:56, Jun Suzuki wrote:

2023年12月15日(金) 20:37 Rémy Maucherat :


On Fri, Dec 15, 2023 at 11:54 AM Jun Suzuki  wrote:


Rémy
Thank you so much for your support.
May I confirm a little bit further regarding your reply.

2023年12月15日(金) 17:08 Rémy Maucherat :


On Fri, Dec 15, 2023 at 4:18 AM Jun Suzuki  wrote:



(1) Guidance is not so clear about following points:
Should I copy the deployed application(with or without war file?) from
existing Tomcat server webapps directory, to webapps directory of
$TOMCAT_STUFFED?
Should I copy all the files from conf directory of existing Tomcat
server, to conf directory of $TOMCAT_STUFFED?


Yes.
When building your image, you have to compile all the classes into it.
So that means all the classes of the webapp as well. So if you don't
copy your webapp for the script to compile, no webapp classes ... Also
all the webapp Java classes and JARs will have to be included in the
image as well for annotation scanning.


Is it correct that following source from existing Tomcat Server needed
to be copied into $TOMCAT_STUFFED?
A.  All files under conf folder (including war file)
B.  All files under webapps folder
C.  How about lib folder? Should it also be copied?
D.  How about java source code(which are not deployed on Tomcat)


The doc is correct, so just use that:
- Copy config files from conf (obvious)
- Webapps go in webapps (unless the host appBase is something else)
And that's it.




(2) On the step of execution of "$JAVA_HOME/bin/java -Dcatalina.base=.
-Djava.util.logging.config.file=conf/logging.properties -jar
target/tomcat-stuffed-1.0.jar --catalina -generateCode src/main/java",
errors messages show as below:
...
Can't load log handler "1catalina.org.apache.juli.AsyncFileHandler"
java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
 at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
 at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
...


Yes, avoid the juli file handlers. There's a jul file handler I think:
java.util.logging.FileHandler


I revised the source code by deleting "import java.util.*", and I
recompiled the java source and copied the war file into
$TOMCAT_STUFFED.
However, the error message remains:
Can't load log handler "1localhost.org.apache.juli.AsyncFileHandler"
java.lang.ClassNotFoundException: 1localhost.org.apache.juli.AsyncFileHandler
...
Can't load log handler "2localhost.org.apache.juli.AsyncFileHandler"
java.lang.ClassNotFoundException: 2localhost.org.apache.juli.AsyncFileHandler


Use stuff from java.util.logging instead if juli doesn't work for you.
Or change the pom to add it. Juli makes things more complex with
Graal, so the pom doesn't have it.
As explained in the doc, the pom needs to be edited for needed dependencies.


...
15-Dec-2023 10:35:47.580 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
web application directory
[/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
[215] ms
15-Dec-2023 10:35:47.580 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
web application directory
[/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
[215] ms
15-Dec-2023 10:35:47.583 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["http-nio-8080"]
15-Dec-2023 10:35:47.583 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["http-nio-8080"]

Since the error messages are showing as above and the process is
hanging on there, I could not proceed with the step of the next "maven
package" unless I open another terminal to run maven command.
Do you have any idea about how to fix this error?


Well, there's no error there, so it's fine. The process is to generate
reflection metadata for your webapp depending on what it needs, so you
need to write a script that exercises all your paths in your webapp
[that would use reflection]. It's kind of like using your webapp
testsuite there. Once that is done, you should shutdown Tomcat as
usual, the metadata has been generated by the agent.
That is explained here:
https://tomcat.apache.org/tomcat-9.0-doc/graal.html#Native_image_configuration

Then you can move on to
https://tomcat.apache.org/tomcat-9.0-doc/graal.html#Building_the_native_image

Rémy

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



Thank you  Rémy for your detailed explanation.
So from your explanation, I understand following

Re: Should allowHostHeaderMismatch be case sensitive

2023-12-15 Thread Mark Thomas 

On 15/12/2023 14:48, Christopher Schultz wrote:

Do we need to argue over encoding and/or rules of 
case-insensitive-matching?


Could we? Probably. Do we need to? Unlikely.

My expectation is that most clients aren't even including the host in 
the request line these days.


Non-ASCII hostnames are allowed these days. Depending upon when this 
comparison is done, the strings may or may not have been normalized. 
Case-normalization can be expensive if you want to be as encoding, 
language, etc. agnostic as possible.


Yes this is a theoretical risk but one I don't expect to materialize. My 
expectation is that clients new enough to use non-ascii host names also 
don't put the header in the request line or if they do, they make sure 
it matches the Host header.


Perhaps we could perform a byte-wise comparison first (which is very 
likely to succeed quickly) and, if that fails, fall-back to a more 
thorough normalization/comparison?


That is probably the way to go if we decide in the future that we do 
need to do the normalization first. In which case I'd lean more towards 
using toString() and then getting Java to do the comparison.


Mark

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

Re: 9.0.83 addSslHostConfig JMX Operation Regression (Sample Code Attached)

2023-12-15 Thread Christopher Schultz 




On 12/15/23 04:27, Rémy Maucherat wrote:

On Thu, Dec 14, 2023 at 7:54 PM Daniel Skiles
 wrote:


Christ,
Thanks for the explanation.

The XML-based registration - is that something I would do as a user, or
something that would be changed on the Tomcat side as part of its release
bundle?


I fixed MbeansDescriptorsIntrospectionSource to allow multiple
operations with the same name. The fix will be in 9.0.85.


+1

Thanks for doing that. I wasn't sure exactly where it should be done, as 
there are a bunch of operations available that aren't defined in the XML 
anywhere. "Fixing" the introspection process is a better move.


-chris


On Thu, Dec 14, 2023 at 10:17 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Daniel,

On 12/14/23 09:43, Daniel Skiles wrote:

Do you have any pointers on how to do that using JMX?  So far as I can

tell

from what little documentation I can find on the tomcat site, this is how
it's done.

I'm suspicious that there might be an issue in
Tomcat's MbeansDescriptorsIntrospectionSource.createManagedBean(...)
method.  I'm not familiar with the code, but it appears that there might

be

an issue with how that map is constructed.


+1

The operations map is keyed on method-name which means that overloads
are not supported.

I suppose it's possible that the introspecter doesn't always get the
methods back from the reflection process in exactly the same order, and
the last one always wins. This would explain why it sometimes works and
sometimes does not work.

The best solution would be to explicitly-define this operation in the
MBeans XML-based registration. Then no introspection is necessary and we
always get the right method.

-chris


On Thu, Dec 14, 2023 at 4:25 AM Rémy Maucherat  wrote:


On Wed, Dec 13, 2023 at 9:43 PM Daniel Skiles
 wrote:


The object and operation I'm trying to address is Catalina -->
ProtocolHandler -->  -->  --> operations -->

addSslHostConfig.


The parameters are an SslHostConfig object and the boolean value

"true".


The operation is "addSslHostConfig".

The code I sent in the previous message works 100% of the time in

9.0.82.

In 9.0.83, it works about 50% of the time.  I can always query that the
operation exists, but roughly half the time it will fail with a JMX
exception saying that the operation does not exist.

I am not positive, but I believe the behavior in 9.0.83 might have to

do

with the fact that the catalina java code now has a one argument and

two

argument variant of the same method.


I'm pretty sure you got the explanation right. It is very similar to
using reflection here. You're doing the lookup based on the method
name, which matches something. However, if you want to avoid an error,
you also have to check that the arguments match, otherwise you're
going to randomly pick one of the two methods and fail half the time.

Rémy


On Wed, Dec 13, 2023 at 10:27 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Daniel,

On 12/12/23 19:45, Daniel Skiles wrote:

I apologize for it being a bit rough - it's what I was using to
troubleshoot locally.

import static java.util.Objects.nonNull;

import java.lang.management.ManagementFactory;
import java.util.Arrays;
import java.util.HashMap;
import java.util.Map;
import java.util.Optional;
import java.util.function.Predicate;

import javax.management.MBeanInfo;
import javax.management.MBeanOperationInfo;
import javax.management.MBeanServer;
import javax.management.ObjectName;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.tomcat.util.net.SSLHostConfig;
import org.apache.tomcat.util.net.SSLHostConfigCertificate;
import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;

@javax.annotation.ManagedBean
public class MbeanFailure {
private static final Logger LOGGER = LogManager.getLogger();

private static final String LOCALHOST = "127.0.0.1";
private static final String SUBTYPE = "subType";
private static final String ADD_SSL_HOST_CONFIG_OP =

"addSslHostConfig";


private static final Predicate NOT_LOCALHOST =

Predicate.not(on

->






Optional.ofNullable(on).map(ObjectName::getCanonicalName).orElse("").contains(LOCALHOST));

private static final Predicate  NOT_SUBTYPE =

Predicate.not(on

->






Optional.ofNullable(on).map(ObjectName::getCanonicalName).orElse("").contains(SUBTYPE));


@javax.annotation.PostConstruct
public void run() throws Exception {
final MBeanServer server =

ManagementFactory.getPlatformMBeanServer();


final SSLHostConfig config = new SSLHostConfig();

config.setProtocols("TLSv1.2");
config.setHostName("test.test.com");
config.setCiphers("TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256");

final SSLHostConfigCertificate cert = new

SSLHostConfigCertificate(config,

Type.UNDEFINED);

config.addCertificate(cert);
final Map references =

getObjectReferences(server,

"ProtocolHandler");

references.forEach((s, op) -> invoke(s, op, ADD_SSL_HOST_CONFIG_OP,

new

Object[] {config}, new

Re: Should allowHostHeaderMismatch be case sensitive

2023-12-15 Thread Christopher Schultz 

Mark,

On 12/15/23 04:12, Mark Thomas wrote:

On 11/12/2023 17:20, Mark Thomas wrote:

On 11/12/2023 17:08, David Cleary wrote:
Just want to check if this is by design. The above property default 
was changed to better secure the default configuration. We started 
having some tests fail due to this.


In our scenario ( as shown below ), the Host header value in the HTTP 
request is case-sensitive difference compared to the Request Line, 
and it's crucial that Tomcat, our web server, does not block or 
reject requests based on variations in the letter case within this 
header.


Request Line: GET http://HZN-OE-A079:8080 HTTP/1.1
Host header: hzn-oe-a079:8080

Just want to confirm that this property, now with a default of false, 
is supposed to reject requests based on the case of the host name.


David,

Host names are case insensitive so I can see the argument for making 
this comparison in a case insensitive manner.


However, the language in RFC 9112, section 3.2 is:

A client MUST send a Host header field (Section 7.2 of [HTTP]) in all 
HTTP/1.1 request messages. If the target URI includes an authority 
component, then a client MUST send a field value for Host that is 
identical to that authority component, excluding any userinfo 
subcomponent and its "@" delimiter (Section 4.2 of [HTTP]).



The key word for me in the above is identical.

We probably need to go back to the HTTP working group and clarify 
whether then intention was for that "identical" to be in a case 
sensitive or insensitive manner.


https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0247.html

Based on that discussion, I am going to relax the check to case 
insensitive.


+1

Do we need to argue over encoding and/or rules of case-insensitive-matching?

Non-ASCII hostnames are allowed these days. Depending upon when this 
comparison is done, the strings may or may not have been normalized. 
Case-normalization can be expensive if you want to be as encoding, 
language, etc. agnostic as possible.


Perhaps we could perform a byte-wise comparison first (which is very 
likely to succeed quickly) and, if that fails, fall-back to a more 
thorough normalization/comparison?


-chris

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

Re: [EXTERNAL] - Re: Partitioned cookies

2023-12-15 Thread Christopher Schultz 

Mark,

On 12/15/23 04:03, Mark Thomas wrote:

On 14/12/2023 21:15, André van der Lugt wrote:


From: Chuck Caldarale 
Sent: Wednesday, November 15, 2023 9:48 AM
To: Tomcat Users List 
Subject: [EXTERNAL] - Re: Partitioned cookies


On Nov 15, 2023, at 08:06, Adam Warfield
 wrote:

The Rfc6265CookieProcessor supports setting the SameSite cookie 
attribute
but starting in 2024, browsers will begin enforcing the newer 
"Partitioned"
attribute for third-party cookies. Is there a way to set this 
attribute within
Tomcat for things like the JSESSIONID and XSRF-TOKEN cookies? This 
affects

any webapps that are embedded within iframes across domains where those
cookies will be rejected if not partitioned.



Looks like the CHIPS proposal:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/


expired this past May and no updated version has been submitted to 
IETF. Is
there some other active standards document describing cookie 
partitioning?


   - Chuck


Standard or not, Google/Chrome is moving on and will (as noted above) 
soon start to gradually reject third-party cookies without the 
Partitioned attribute.


I'm kindly asking the experts: is Tomcat support for this feature 
being planned?


No.


If not, what can be done to modestly prioritize it?


Open an enhancement request in Bugzilla. Better still, provide a PR to 
implement the change.


No need, right? Tomcat 10 has Cookie.setAttribute(), as I mentioned back 
on 2023-11-16 in response to the OP.


-chris

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

Re: I can't find how to stop TOMCAT during INITIALIZATION phase

2023-12-15 Thread Christopher Schultz 

All,

On 12/15/23 03:29, Simon Matter wrote:

Hi,



Our question is:
1. It is possible to stop tomcat during initialization phase?
2. If yes how and if not are any plans to implement it in future versions?

It seems to me that my solutions for now are:
1. sending SIGKILL signal to tomcat (this is very risky to me because
stopping like this in the middle of something may corrupt data - but this
situation is any way possible so I have to handle it)
2. wait for tomcat initilization procedure to finish and then trigger the
shutdown since we can do something in our wrapper scripts
Do you see any other possible solutions?



Did you try to terminate the process with SIGUSR1 instead of SIGKILL? I
usually terminate Java processes with SIGUSR1 if SIGTERM is not handled in
time and it still seems to do some cleanup while shutting down.


Try SIGTERM. You will still have to decide how to "avoid corruption" as 
far as your application is concerned.


-chris

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

Re: Issues of Ahead of Time compilation support

2023-12-15 Thread Jun Suzuki 
2023年12月15日(金) 20:37 Rémy Maucherat :
>
> On Fri, Dec 15, 2023 at 11:54 AM Jun Suzuki  wrote:
> >
> > Rémy
> > Thank you so much for your support.
> > May I confirm a little bit further regarding your reply.
> >
> > 2023年12月15日(金) 17:08 Rémy Maucherat :
> > >
> > > On Fri, Dec 15, 2023 at 4:18 AM Jun Suzuki  
> > > wrote:
> >
> > > > (1) Guidance is not so clear about following points:
> > > > Should I copy the deployed application(with or without war file?) from
> > > > existing Tomcat server webapps directory, to webapps directory of
> > > > $TOMCAT_STUFFED?
> > > > Should I copy all the files from conf directory of existing Tomcat
> > > > server, to conf directory of $TOMCAT_STUFFED?
> > >
> > > Yes.
> > > When building your image, you have to compile all the classes into it.
> > > So that means all the classes of the webapp as well. So if you don't
> > > copy your webapp for the script to compile, no webapp classes ... Also
> > > all the webapp Java classes and JARs will have to be included in the
> > > image as well for annotation scanning.
> >
> > Is it correct that following source from existing Tomcat Server needed
> > to be copied into $TOMCAT_STUFFED?
> > A.  All files under conf folder (including war file)
> > B.  All files under webapps folder
> > C.  How about lib folder? Should it also be copied?
> > D.  How about java source code(which are not deployed on Tomcat)
>
> The doc is correct, so just use that:
> - Copy config files from conf (obvious)
> - Webapps go in webapps (unless the host appBase is something else)
> And that's it.
>
> > >
> > > > (2) On the step of execution of "$JAVA_HOME/bin/java -Dcatalina.base=.
> > > > -Djava.util.logging.config.file=conf/logging.properties -jar
> > > > target/tomcat-stuffed-1.0.jar --catalina -generateCode src/main/java",
> > > > errors messages show as below:
> > > > ...
> > > > Can't load log handler "1catalina.org.apache.juli.AsyncFileHandler"
> > > > java.lang.ClassNotFoundException: 
> > > > 1catalina.org.apache.juli.AsyncFileHandler
> > > > java.lang.ClassNotFoundException: 
> > > > 1catalina.org.apache.juli.AsyncFileHandler
> > > > at 
> > > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> > > > at 
> > > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> > > > at 
> > > > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
> > > > ...
> > >
> > > Yes, avoid the juli file handlers. There's a jul file handler I think:
> > > java.util.logging.FileHandler
> >
> > I revised the source code by deleting "import java.util.*", and I
> > recompiled the java source and copied the war file into
> > $TOMCAT_STUFFED.
> > However, the error message remains:
> > Can't load log handler "1localhost.org.apache.juli.AsyncFileHandler"
> > java.lang.ClassNotFoundException: 
> > 1localhost.org.apache.juli.AsyncFileHandler
> > ...
> > Can't load log handler "2localhost.org.apache.juli.AsyncFileHandler"
> > java.lang.ClassNotFoundException: 
> > 2localhost.org.apache.juli.AsyncFileHandler
>
> Use stuff from java.util.logging instead if juli doesn't work for you.
> Or change the pom to add it. Juli makes things more complex with
> Graal, so the pom doesn't have it.
> As explained in the doc, the pom needs to be edited for needed dependencies.
>
> > ...
> > 15-Dec-2023 10:35:47.580 INFO [main]
> > org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
> > web application directory
> > [/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
> > [215] ms
> > 15-Dec-2023 10:35:47.580 INFO [main]
> > org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
> > web application directory
> > [/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
> > [215] ms
> > 15-Dec-2023 10:35:47.583 INFO [main]
> > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> > ["http-nio-8080"]
> > 15-Dec-2023 10:35:47.583 INFO [main]
> > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> > ["http-nio-8080"]
> >
> > Since the error messages are showing as above and the process is
> > hanging on there, I could not proceed with the step of the next "maven
> > package" unless I open another terminal to run maven command.
> > Do you have any idea about how to fix this error?
>
> Well, there's no error there, so it's fine. The process is to generate
> reflection metadata for your webapp depending on what it needs, so you
> need to write a script that exercises all your paths in your webapp
> [that would use reflection]. It's kind of like using your webapp
> testsuite there. Once that is done, you should shutdown Tomcat as
> usual, the metadata has been generated by the agent.
> That is explained here:
>

Re: Issues of Ahead of Time compilation support

2023-12-15 Thread Rémy Maucherat 
On Fri, Dec 15, 2023 at 11:54 AM Jun Suzuki  wrote:
>
> Rémy
> Thank you so much for your support.
> May I confirm a little bit further regarding your reply.
>
> 2023年12月15日(金) 17:08 Rémy Maucherat :
> >
> > On Fri, Dec 15, 2023 at 4:18 AM Jun Suzuki  wrote:
>
> > > (1) Guidance is not so clear about following points:
> > > Should I copy the deployed application(with or without war file?) from
> > > existing Tomcat server webapps directory, to webapps directory of
> > > $TOMCAT_STUFFED?
> > > Should I copy all the files from conf directory of existing Tomcat
> > > server, to conf directory of $TOMCAT_STUFFED?
> >
> > Yes.
> > When building your image, you have to compile all the classes into it.
> > So that means all the classes of the webapp as well. So if you don't
> > copy your webapp for the script to compile, no webapp classes ... Also
> > all the webapp Java classes and JARs will have to be included in the
> > image as well for annotation scanning.
>
> Is it correct that following source from existing Tomcat Server needed
> to be copied into $TOMCAT_STUFFED?
> A.  All files under conf folder (including war file)
> B.  All files under webapps folder
> C.  How about lib folder? Should it also be copied?
> D.  How about java source code(which are not deployed on Tomcat)

The doc is correct, so just use that:
- Copy config files from conf (obvious)
- Webapps go in webapps (unless the host appBase is something else)
And that's it.

> >
> > > (2) On the step of execution of "$JAVA_HOME/bin/java -Dcatalina.base=.
> > > -Djava.util.logging.config.file=conf/logging.properties -jar
> > > target/tomcat-stuffed-1.0.jar --catalina -generateCode src/main/java",
> > > errors messages show as below:
> > > ...
> > > Can't load log handler "1catalina.org.apache.juli.AsyncFileHandler"
> > > java.lang.ClassNotFoundException: 
> > > 1catalina.org.apache.juli.AsyncFileHandler
> > > java.lang.ClassNotFoundException: 
> > > 1catalina.org.apache.juli.AsyncFileHandler
> > > at 
> > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> > > at 
> > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> > > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
> > > ...
> >
> > Yes, avoid the juli file handlers. There's a jul file handler I think:
> > java.util.logging.FileHandler
>
> I revised the source code by deleting "import java.util.*", and I
> recompiled the java source and copied the war file into
> $TOMCAT_STUFFED.
> However, the error message remains:
> Can't load log handler "1localhost.org.apache.juli.AsyncFileHandler"
> java.lang.ClassNotFoundException: 1localhost.org.apache.juli.AsyncFileHandler
> ...
> Can't load log handler "2localhost.org.apache.juli.AsyncFileHandler"
> java.lang.ClassNotFoundException: 2localhost.org.apache.juli.AsyncFileHandler

Use stuff from java.util.logging instead if juli doesn't work for you.
Or change the pom to add it. Juli makes things more complex with
Graal, so the pom doesn't have it.
As explained in the doc, the pom needs to be edited for needed dependencies.

> ...
> 15-Dec-2023 10:35:47.580 INFO [main]
> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
> web application directory
> [/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
> [215] ms
> 15-Dec-2023 10:35:47.580 INFO [main]
> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
> web application directory
> [/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
> [215] ms
> 15-Dec-2023 10:35:47.583 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-nio-8080"]
> 15-Dec-2023 10:35:47.583 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-nio-8080"]
>
> Since the error messages are showing as above and the process is
> hanging on there, I could not proceed with the step of the next "maven
> package" unless I open another terminal to run maven command.
> Do you have any idea about how to fix this error?

Well, there's no error there, so it's fine. The process is to generate
reflection metadata for your webapp depending on what it needs, so you
need to write a script that exercises all your paths in your webapp
[that would use reflection]. It's kind of like using your webapp
testsuite there. Once that is done, you should shutdown Tomcat as
usual, the metadata has been generated by the agent.
That is explained here:
https://tomcat.apache.org/tomcat-9.0-doc/graal.html#Native_image_configuration

Then you can move on to
https://tomcat.apache.org/tomcat-9.0-doc/graal.html#Building_the_native_image

Rémy

-
To unsubscribe, e-mail:

Re: Issues of Ahead of Time compilation support

2023-12-15 Thread Jun Suzuki 
Rémy
Thank you so much for your support.
May I confirm a little bit further regarding your reply.

2023年12月15日(金) 17:08 Rémy Maucherat :
>
> On Fri, Dec 15, 2023 at 4:18 AM Jun Suzuki  wrote:

> > (1) Guidance is not so clear about following points:
> > Should I copy the deployed application(with or without war file?) from
> > existing Tomcat server webapps directory, to webapps directory of
> > $TOMCAT_STUFFED?
> > Should I copy all the files from conf directory of existing Tomcat
> > server, to conf directory of $TOMCAT_STUFFED?
>
> Yes.
> When building your image, you have to compile all the classes into it.
> So that means all the classes of the webapp as well. So if you don't
> copy your webapp for the script to compile, no webapp classes ... Also
> all the webapp Java classes and JARs will have to be included in the
> image as well for annotation scanning.

Is it correct that following source from existing Tomcat Server needed
to be copied into $TOMCAT_STUFFED?
A.  All files under conf folder (including war file)
B.  All files under webapps folder
C.  How about lib folder? Should it also be copied?
D.  How about java source code(which are not deployed on Tomcat)

>
> > (2) On the step of execution of "$JAVA_HOME/bin/java -Dcatalina.base=.
> > -Djava.util.logging.config.file=conf/logging.properties -jar
> > target/tomcat-stuffed-1.0.jar --catalina -generateCode src/main/java",
> > errors messages show as below:
> > ...
> > Can't load log handler "1catalina.org.apache.juli.AsyncFileHandler"
> > java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
> > java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
> > at 
> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> > at 
> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
> > ...
>
> Yes, avoid the juli file handlers. There's a jul file handler I think:
> java.util.logging.FileHandler

I revised the source code by deleting "import java.util.*", and I
recompiled the java source and copied the war file into
$TOMCAT_STUFFED.
However, the error message remains:
Can't load log handler "1localhost.org.apache.juli.AsyncFileHandler"
java.lang.ClassNotFoundException: 1localhost.org.apache.juli.AsyncFileHandler
...
Can't load log handler "2localhost.org.apache.juli.AsyncFileHandler"
java.lang.ClassNotFoundException: 2localhost.org.apache.juli.AsyncFileHandler
...
15-Dec-2023 10:35:47.580 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
web application directory
[/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
[215] ms
15-Dec-2023 10:35:47.580 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of
web application directory
[/home/opc/project/tomcat-native/stuffed/webapps/ROOT] has finished in
[215] ms
15-Dec-2023 10:35:47.583 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["http-nio-8080"]
15-Dec-2023 10:35:47.583 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["http-nio-8080"]

Since the error messages are showing as above and the process is
hanging on there, I could not proceed with the step of the next "maven
package" unless I open another terminal to run maven command.
Do you have any idea about how to fix this error?

Thank you

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

Re: security-constraint url-pattern question

2023-12-15 Thread Mark Thomas 

On 14/12/2023 17:28, ResSoft wrote:

Chris,

I figured out how to make this work.  It works in my dev dox but not in 
my prod box.  Both have the same version of tomcat.  Here is the web.xml entry. 
 I any ideas would be great.


Those constraints look correct to me and a quick test using the examples 
webapp with a default Tomcat install confirms that.


I think you need to look for differences between dev and prod.




 securedapp
 /*
 
 
   CONFIDENTIAL
 
   

 
  



HTTP-Protected-Resource-1
Description here
/path to directory/*
GET
POST


You *really* don't want to be specifying HTTP methods here.

Google for "uncovered HTTP methods"









Mark

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

Re: 9.0.83 addSslHostConfig JMX Operation Regression (Sample Code Attached)

2023-12-15 Thread Rémy Maucherat 
On Thu, Dec 14, 2023 at 7:54 PM Daniel Skiles
 wrote:
>
> Christ,
> Thanks for the explanation.
>
> The XML-based registration - is that something I would do as a user, or
> something that would be changed on the Tomcat side as part of its release
> bundle?

I fixed MbeansDescriptorsIntrospectionSource to allow multiple
operations with the same name. The fix will be in 9.0.85.

Rémy


> On Thu, Dec 14, 2023 at 10:17 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Daniel,
> >
> > On 12/14/23 09:43, Daniel Skiles wrote:
> > > Do you have any pointers on how to do that using JMX?  So far as I can
> > tell
> > > from what little documentation I can find on the tomcat site, this is how
> > > it's done.
> > >
> > > I'm suspicious that there might be an issue in
> > > Tomcat's MbeansDescriptorsIntrospectionSource.createManagedBean(...)
> > > method.  I'm not familiar with the code, but it appears that there might
> > be
> > > an issue with how that map is constructed.
> >
> > +1
> >
> > The operations map is keyed on method-name which means that overloads
> > are not supported.
> >
> > I suppose it's possible that the introspecter doesn't always get the
> > methods back from the reflection process in exactly the same order, and
> > the last one always wins. This would explain why it sometimes works and
> > sometimes does not work.
> >
> > The best solution would be to explicitly-define this operation in the
> > MBeans XML-based registration. Then no introspection is necessary and we
> > always get the right method.
> >
> > -chris
> >
> > > On Thu, Dec 14, 2023 at 4:25 AM Rémy Maucherat  wrote:
> > >
> > >> On Wed, Dec 13, 2023 at 9:43 PM Daniel Skiles
> > >>  wrote:
> > >>>
> > >>> The object and operation I'm trying to address is Catalina -->
> > >>> ProtocolHandler -->  -->  --> operations -->
> > >> addSslHostConfig.
> > >>>
> > >>> The parameters are an SslHostConfig object and the boolean value
> > "true".
> > >>>
> > >>> The operation is "addSslHostConfig".
> > >>>
> > >>> The code I sent in the previous message works 100% of the time in
> > 9.0.82.
> > >>> In 9.0.83, it works about 50% of the time.  I can always query that the
> > >>> operation exists, but roughly half the time it will fail with a JMX
> > >>> exception saying that the operation does not exist.
> > >>>
> > >>> I am not positive, but I believe the behavior in 9.0.83 might have to
> > do
> > >>> with the fact that the catalina java code now has a one argument and
> > two
> > >>> argument variant of the same method.
> > >>
> > >> I'm pretty sure you got the explanation right. It is very similar to
> > >> using reflection here. You're doing the lookup based on the method
> > >> name, which matches something. However, if you want to avoid an error,
> > >> you also have to check that the arguments match, otherwise you're
> > >> going to randomly pick one of the two methods and fail half the time.
> > >>
> > >> Rémy
> > >>
> > >>> On Wed, Dec 13, 2023 at 10:27 AM Christopher Schultz <
> > >>> ch...@christopherschultz.net> wrote:
> > >>>
> >  Daniel,
> > 
> >  On 12/12/23 19:45, Daniel Skiles wrote:
> > > I apologize for it being a bit rough - it's what I was using to
> > > troubleshoot locally.
> > >
> > > import static java.util.Objects.nonNull;
> > >
> > > import java.lang.management.ManagementFactory;
> > > import java.util.Arrays;
> > > import java.util.HashMap;
> > > import java.util.Map;
> > > import java.util.Optional;
> > > import java.util.function.Predicate;
> > >
> > > import javax.management.MBeanInfo;
> > > import javax.management.MBeanOperationInfo;
> > > import javax.management.MBeanServer;
> > > import javax.management.ObjectName;
> > >
> > > import org.apache.logging.log4j.LogManager;
> > > import org.apache.logging.log4j.Logger;
> > > import org.apache.tomcat.util.net.SSLHostConfig;
> > > import org.apache.tomcat.util.net.SSLHostConfigCertificate;
> > > import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
> > >
> > > @javax.annotation.ManagedBean
> > > public class MbeanFailure {
> > > private static final Logger LOGGER = LogManager.getLogger();
> > >
> > > private static final String LOCALHOST = "127.0.0.1";
> > > private static final String SUBTYPE = "subType";
> > > private static final String ADD_SSL_HOST_CONFIG_OP =
> > >> "addSslHostConfig";
> > >
> > > private static final Predicate NOT_LOCALHOST =
> >  Predicate.not(on
> > > ->
> > >
> > 
> > >>
> > Optional.ofNullable(on).map(ObjectName::getCanonicalName).orElse("").contains(LOCALHOST));
> > > private static final Predicate  NOT_SUBTYPE =
> >  Predicate.not(on
> > > ->
> > >
> > 
> > >>
> > Optional.ofNullable(on).map(ObjectName::getCanonicalName).orElse("").contains(SUBTYPE));
> > >
> > > @javax.annotation.PostConstruct
> > > public void run() throws

Re: Should allowHostHeaderMismatch be case sensitive

2023-12-15 Thread Mark Thomas 

On 11/12/2023 17:20, Mark Thomas wrote:

On 11/12/2023 17:08, David Cleary wrote:
Just want to check if this is by design. The above property default 
was changed to better secure the default configuration. We started 
having some tests fail due to this.


In our scenario ( as shown below ), the Host header value in the HTTP 
request is case-sensitive difference compared to the Request Line, and 
it's crucial that Tomcat, our web server, does not block or reject 
requests based on variations in the letter case within this header.


Request Line: GET http://HZN-OE-A079:8080 HTTP/1.1
Host header: hzn-oe-a079:8080

Just want to confirm that this property, now with a default of false, 
is supposed to reject requests based on the case of the host name.


David,

Host names are case insensitive so I can see the argument for making 
this comparison in a case insensitive manner.


However, the language in RFC 9112, section 3.2 is:

A client MUST send a Host header field (Section 7.2 of [HTTP]) in all 
HTTP/1.1 request messages. If the target URI includes an authority 
component, then a client MUST send a field value for Host that is 
identical to that authority component, excluding any userinfo 
subcomponent and its "@" delimiter (Section 4.2 of [HTTP]).



The key word for me in the above is identical.

We probably need to go back to the HTTP working group and clarify 
whether then intention was for that "identical" to be in a case 
sensitive or insensitive manner.


https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0247.html

Based on that discussion, I am going to relax the check to case insensitive.

Mark

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

Re: [EXTERNAL] - Re: Partitioned cookies

2023-12-15 Thread Mark Thomas 

On 14/12/2023 21:15, André van der Lugt wrote:


From: Chuck Caldarale 
Sent: Wednesday, November 15, 2023 9:48 AM
To: Tomcat Users List 
Subject: [EXTERNAL] - Re: Partitioned cookies


On Nov 15, 2023, at 08:06, Adam Warfield
 wrote:

The Rfc6265CookieProcessor supports setting the SameSite cookie attribute
but starting in 2024, browsers will begin enforcing the newer "Partitioned"
attribute for third-party cookies. Is there a way to set this attribute within
Tomcat for things like the JSESSIONID and XSRF-TOKEN cookies? This affects
any webapps that are embedded within iframes across domains where those
cookies will be rejected if not partitioned.



Looks like the CHIPS proposal:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/


expired this past May and no updated version has been submitted to IETF. Is
there some other active standards document describing cookie partitioning?

   - Chuck


Standard or not, Google/Chrome is moving on and will (as noted above) soon 
start to gradually reject third-party cookies without the Partitioned attribute.

I'm kindly asking the experts: is Tomcat support for this feature being planned?


No.


If not, what can be done to modestly prioritize it?


Open an enhancement request in Bugzilla. Better still, provide a PR to 
implement the change.


Mark

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

Re: I can't find how to stop TOMCAT during INITIALIZATION phase

2023-12-15 Thread Simon Matter 
Hi,

>
> Our question is:
> 1. It is possible to stop tomcat during initialization phase?
> 2. If yes how and if not are any plans to implement it in future versions?
>
> It seems to me that my solutions for now are:
> 1. sending SIGKILL signal to tomcat (this is very risky to me because
> stopping like this in the middle of something may corrupt data - but this
> situation is any way possible so I have to handle it)
> 2. wait for tomcat initilization procedure to finish and then trigger the
> shutdown since we can do something in our wrapper scripts
> Do you see any other possible solutions?
>

Did you try to terminate the process with SIGUSR1 instead of SIGKILL? I
usually terminate Java processes with SIGUSR1 if SIGTERM is not handled in
time and it still seems to do some cleanup while shutting down.

Regards,
Simon


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

Re: Issues of Ahead of Time compilation support

2023-12-15 Thread Rémy Maucherat 
On Fri, Dec 15, 2023 at 4:18 AM Jun Suzuki  wrote:
>
> Hello all,
>
> Does anyone have experience of implementation of AOT/GraalVM by
> following official documentation as below?
> https://tomcat.apache.org/tomcat-9.0-doc/graal.html
>
> I created a simple spring framework application(deployed as a war
> file) which is working well under Tomcat10.x, GraalVM21 with JDK21.
> Then I'm trying to transform the application into native image based
> on the documentation.
> I download the Tomcat Stuffed module and started to do packaging and building.
> However, I encountered some issues by following the steps from the
> documentation.
>
> (1) Guidance is not so clear about following points:
> Should I copy the deployed application(with or without war file?) from
> existing Tomcat server webapps directory, to webapps directory of
> $TOMCAT_STUFFED?
> Should I copy all the files from conf directory of existing Tomcat
> server, to conf directory of $TOMCAT_STUFFED?

Yes.
When building your image, you have to compile all the classes into it.
So that means all the classes of the webapp as well. So if you don't
copy your webapp for the script to compile, no webapp classes ... Also
all the webapp Java classes and JARs will have to be included in the
image as well for annotation scanning.

> (2) On the step of execution of "$JAVA_HOME/bin/java -Dcatalina.base=.
> -Djava.util.logging.config.file=conf/logging.properties -jar
> target/tomcat-stuffed-1.0.jar --catalina -generateCode src/main/java",
> errors messages show as below:
> ...
> Can't load log handler "1catalina.org.apache.juli.AsyncFileHandler"
> java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
> java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
> ...

Yes, avoid the juli file handlers. There's a jul file handler I think:
java.util.logging.FileHandler

> (3) When using JDK17, the first step of maven build failed with following 
> error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile
> (default-compile) on project tomcat-stuffed: Fatal error compiling:
> error: release version 21 not supported.
> After I switched to JDK21, build completed successfully. Is the
> approach only support JDK21?

Yes, if you take the path to stuffed that is mentioned in the docs, it
will be from the "main" Tomcat branch, which means Java 21 (it got
updated since). The module exists on the "10.1.x" branch as well,
where it is Java 11 instead, matching Tomcat 10.1. Don't be afraid to
change the release target and Tomcat version used in the pom.
I'll update the graal.html to at least point to the 10.1.x branch.

Rémy

> Please kindly provide any insights on this.
> Thank you
>
> Jun
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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