Re: (tomcat) branch main updated: Various minor fixes and improvements from code review

On 08/07/2026 14:47, [email protected] wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> rmaucher pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/main by this push:
>       new ad7c287456 Various minor fixes and improvements from code review
> ad7c287456 is described below
> 
> commit ad7c2874563f8a53da7294d526992a1e53da6789
> Author: remm <[email protected]>
> AuthorDate: Wed Jul 8 15:47:30 2026 +0200
> 
>      Various minor fixes and improvements from code review

<snip/>

> --- a/java/org/apache/catalina/tribes/Channel.java
> +++ b/java/org/apache/catalina/tribes/Channel.java

<snip/>

> @@ -291,16 +266,16 @@ public interface Channel {
>        *                <li>SND_RX_SEQ - stops the replication receiver</li>
>        *                </ul>
>        *
> -     * @throws ChannelException if a startup error occurs or the service is already stopped or an error occurs.
> +     * @throws ChannelException if a shutdown error occurs or the service is already stopped or an error occurs.
>        */
>       void stop(int svc) throws ChannelException;
>   
>       /**
>        * Send a message to one or more members in the cluster
>        *
> -     * @param destination Member[] - the destinations, cannot be null or zero length, the reason for that is that a
> -     *                        membership change can occur and at that time the application is uncertain what group the
> -     *                        message actually got sent to.
> +     * @param destination Member[] - the destinations, null or zero length means all members. Note that a membership
> +     *                        change can occur between obtaining the member list and sending the message, so the
> +     *                        application is uncertain what group the message actually got sent to.

This doesn't agree with the implementation. There, null or zero length 
will trigger a ChannelException.

The code has been like that for 20 years so I think updating the Javadoc 
is the right way to go.

Mark