Using AUTH on jgroups 5.2.2 runs into a NullPointerException

[NikitaMatckevich]

This issue is related to discussion #641.

As far as I understand, the fix was applied only locally for X509Token. I am using RegexMembership and it fails with NPE in a similar way. The stack trace is like this:

ProtoclStack#initProtocolStack calls AUTH#init
AUTH#init calls RegexMembership#init
RegexMembership fields such as match_string are not yet initialized at this stage, so NPE is thrown

The issue is, as before, the order of operations here:

public void initProtocolStack(List<ProtocolConfiguration> configs, ProtocolHook afterCreationHook) throws Exception {
        List<Protocol> protocols=getProtocols();
        Collections.reverse(protocols);
        try {
            for(int i=0; i < protocols.size(); i++) {
                Protocol prot=protocols.get(i);
                if(prot.getProtocolStack() == null)
                    prot.setProtocolStack(this);
                callAfterCreationHook(prot, prot.afterCreationHook());
                if (afterCreationHook != null) {
                    afterCreationHook.afterCreation(prot);
                }
                prot.init(); // Here components are not yet initialized. The NPE will be thrown.
                initComponents(prot, configs != null? configs.get(i) : null); // Here the initialization is done.

                // sanity checking via policies:
                List<? extends Policy> pols=prot.getPolicies();
                if(pols != null && !pols.isEmpty()) {
                    for(Policy p: pols)
                        p.check(prot);
                }
            }
        }
        catch(Exception ex) {
            this.destroy();
            throw ex;
        }
    }

A solution is, as was suggested in a previous discussion, to move some checks from RegexMembership#init() to RegexMembership#start().

For example, I tweak the token like this:

public class CustomRegexMembership extends RegexMembership {

	@Override
	public void init() throws Exception {
		if (!match_ip_address && !match_logical_name) {
			throw new IllegalArgumentException("either match_ip_address or match_logical_address has to be true");
		}
	}

	@Override
	public void start() throws Exception {
		if (match_string == null) {
			throw new IllegalArgumentException("match_string cannot be null");
		}
		pattern = Pattern.compile(match_string);
	}

}

We can move this behavior to the core if you want. I can open a PR if needed.

[NikitaMatckevich]

I think this problem may be not limited by 1 or 2 token types. It may also occur with other types of tokens, but I didn't verify that.

[belaban]

Sorry for the delay! Yes, you're right, this is a bug. If you create a PR, I'll create the JIRA... However, I'm on PTO for 2 weeks and won't be able to get to this before the week of June 24...

[NikitaMatckevich]

#800

[NikitaMatckevich]

No problem, this can wait. Thank you!

[belaban]

I created https://issues.redhat.com/browse/JGRP-2803

[belaban]

Applied to master, 5.3.x and 5.2.x branches. If you find other AUTH tokens having the same issue, please let me know.
I appeciate you submitting a PR, as I'm busy with other stuff and this would not be on top of my todo list!
Thanks!