[JBWS-4385]:This fix starts with Brad Maxwell's proposed change and a…

[jimma]

…dded a JAXPDelegateClassLoader to Protect the jbossws runtime from loading the jaxp impl from user's deployment

[jimma]

@bmaxwell Could you please review this change ?

[bmaxwell]

@jimma it works with the test app I had , Thanks!

[NiasSt90]

However, this leads to a problem with SOAP interceptors from the deployment that want to use CDI.
These no longer work with this adjustment, because CDI (CDI.current()) no longer sees the deployment class loader but the wrapper.
This will break all of our SOAP-Services which depends on cdi.
Any ideas how to circumvent this?

[NiasSt90]

@jimma @bmaxwell

Is this the only workaround with the new TCCL wrapper to savely access CDI/Deployment-Classloader Features inside of Interceptor implementations?

public class CDIInterceptor extends AbstractPhaseInterceptor<Message> {

	public CDIInterceptor() {
		super(Phase.RECEIVE);
	}


	@Override
	public void handleMessage(Message message) throws Fault {
		var tccl = Thread.currentThread().getContextClassLoader();
		try {
			Thread.currentThread().setContextClassLoader(CDIInterceptor.class.getClassLoader());
			System.out.println("Now it's save to access CDI:" + CDI.current().getBeanManager());
		}
		finally {
			Thread.currentThread().setContextClassLoader(tccl);
		}
	}
}

[jimma]

@NiasSt90 I fixed this issue with PR for https://issues.redhat.com/browse/JBWS-4430, and working for another fix : https://issues.redhat.com/browse/JBWS-4444 (#582)