[JBoss JIRA] (WFLY-13502) UT000010: Session is invalid
by Cristian VL (Jira)
[ https://issues.redhat.com/browse/WFLY-13502?page=com.atlassian.jira.plugi... ]
Cristian VL commented on WFLY-13502:
------------------------------------
The error is in fact an Exception thrown by Undertow system but it is not caught or handled by Weld. There are multiple threads working on that session and one of them invalidate the session and the state it is not propagated by Undertow.
> UT000010: Session is invalid
> -----------------------------
>
> Key: WFLY-13502
> URL: https://issues.redhat.com/browse/WFLY-13502
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Final, 16.0.0.Final
> Reporter: Cristian VL
> Assignee: Flavia Rainone
> Priority: Critical
>
> 2020-05-21 06:00:22,239 ERROR [org.jboss.threads.errors] (default task-1145) Thread Thread[default task-1145,5,main] threw an uncaught exception: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session is invalid X0SZbaIu078s8ChCz8YIJON59sTmY7gV2bopjwlm
> at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:1029)
> at io.undertow.servlet.spec.AsyncContextImpl.onAsyncComplete(AsyncContextImpl.java:614)
> at io.undertow.servlet.spec.AsyncContextImpl.access$100(AsyncContextImpl.java:73)
> at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:316)
> at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:485)
> at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:604)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: UT000010: Session is invalid X0SZbaIu078s8ChCz8YIJON59sTmY7gV2bopjwlm
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:512)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122)
> at org.jboss.weld.module.web.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:37)
> at org.jboss.weld.module.web.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:18)
> at org.jboss.weld.contexts.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:179)
> at org.jboss.weld.contexts.AbstractConversationContext.dissociate(AbstractConversationContext.java:157)
> at org.jboss.weld.module.web.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:116)
> at org.jboss.weld.module.web.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:254)
> at org.jboss.weld.module.web.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
> at io.undertow.servlet.spec.AsyncContextImpl.setupRequestContext(AsyncContextImpl.java:706)
> at io.undertow.servlet.spec.AsyncContextImpl.access$700(AsyncContextImpl.java:73)
> at io.undertow.servlet.spec.AsyncContextImpl$7.run(AsyncContextImpl.java:619)
> at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:181)
> at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:178)
> at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:1027)
> ... 10 more
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13498) @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-13498?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-13498:
--------------------------------------
bq. We migrated our application from Wildfly 9 and Java 8 to Wildfly 16 and Java 11. Maybe something in our configuration is resulting in this issue. Would the size of the application make a difference, could it result in a timing/race condition?
Hmm, don't think so, at least I can't think of a way to affect that.
bq. When I debugged through the issue over a month ago, I noticed that org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments hadn't processed all CDI beans in the lib jars before the ServletContext was initialized. Should this be the case?
Even if that were the case, you should still be getting the event with {{Object}} payload.
> @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
> --------------------------------------------------------------
>
> Key: WFLY-13498
> URL: https://issues.redhat.com/browse/WFLY-13498
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 16.0.0.Final
> Reporter: Fearghal O Maolcatha
> Assignee: Matěj Novotný
> Priority: Major
>
> I have an @ApplicationScoped bean that I want to be instantiated on application startup (see sample code below). I've registered for the servlet context initialization event but the init method is never invoked. The FactoryLocator is contained in a jar within my war's WEB-INF/lib directory. This same code was working on Wildfly 9 but no longer works after upgrading to Wildfly 16.
> {code:java}
> import javax.enterprise.context.ApplicationScoped;
> import javax.enterprise.context.Initialized;
> import javax.enterprise.event.Observes;
> import javax.servlet.ServletContext;
> @ApplicationScoped
> public class FactoryLocator {
> public FactoryLocator() {
> System.out.println("In the constructor.........................");
> }
> private void init(@Observes @Initialized(ApplicationScoped.class) ServletContext sc) {
> System.out.println("Invoking the event observer method..................");
> }
> }
> {code}
> One workaround I discovered was to extract the contents of the jars in my war's WEB-INF/lib/ directory to my war's WEB-INF/classes directory. When I did this my FactorLocator bean was instantiated successfully. I'd prefer not to have to do this.
> After debugging through the war's deployment, I noticed that the ServletContext is initialized before all the beans in the war's lib directory are processed (org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments). The war's module is not aware of all observers until all the beans are processed. However, the ServletContextEvent is fired before all the observers are known.
> Should this happen that ServletContext is created before all observers are known about? I've debugged one of the Wildfly QuickStart applications and the ServletContext isn't created until all bean deployments are processed and the code below is executed successfully. Is the order in which this happens supposed to be guaranteed?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5353) Avoid ClassLoader retention in LambdaIntrospector
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5353:
-----------------------------------------
Summary: Avoid ClassLoader retention in LambdaIntrospector
Key: DROOLS-5353
URL: https://issues.redhat.com/browse/DROOLS-5353
Project: Drools
Issue Type: Enhancement
Components: executable model
Affects Versions: 7.37.0.Final
Reporter: Toshiya Kobayashi
Assignee: Toshiya Kobayashi
Fix For: 7.38.0.Final
Change LambdaIntrospector$ClassIdentifier not to retain ClassLoader itself so that we no longer need to worry about ClassLoader leak.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-5966?page=com.atlassian.jira.plugin... ]
Yeray Borges Santana updated WFLY-5966:
---------------------------------------
Description:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml-
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
-feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
-jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml-
-jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml-
-jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml-
-jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml-
-jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml-
was:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
-feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
-jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml-
-jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml-
-jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml-
-jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml-
-jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml-
Yes [~brian.stansberry], thanks, I forgot it.
Finally with WFCORE-4621 resolved it got done, I leave it up to you to set the proper fix version, technically it was in 12.0.0.Beta1.
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.redhat.com/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Major
> Fix For: 18.0.0.Beta1, 18.0.0.Final
>
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> -feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml-
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> -feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
> -jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml-
> -jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml-
> -jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml-
> -jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml-
> -jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml-
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4976) Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4976?page=com.atlassian.jira.plug... ]
Darran Lofthouse moved ELY-1969 to WFCORE-4976:
-----------------------------------------------
Project: WildFly Core (was: WildFly Elytron)
Key: WFCORE-4976 (was: ELY-1969)
Component/s: Management
Security
(was: Authentication Client)
Fix Version/s: 12.0.0.Beta4
(was: 1.12.0.CR4)
> Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4976
> URL: https://issues.redhat.com/browse/WFCORE-4976
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 12.0.0.Beta4
>
>
> In ProtocolConnectionUtils we have the following code to pass in the provided CallbackHanldler: -
> {code:java}
> if (handler != null) {
> mergedConfiguration = mergedConfiguration.useCallbackHandler(handler, DEFAULT_CALLBACK_KINDS);
> }
> {code}
> However the AuthenticationClient performs the following sanitation of the specified KINDS: -
> {code:java}
> case SET_USER_CB_KINDS:
> // SANITAZE on above content
> if (this.principal != null) {
> sanitazeOnMutation(SET_PRINCIPAL);
> }
> if (this.credentialSource != null) {
> sanitazeOnMutation(SET_CRED_SOURCE);
> }
> if (this.setRealm != null) {
> sanitazeOnMutation(SET_REALM);
> }
> if (this.parameterSpecs != null) {
> sanitazeOnMutation(SET_PARAM_SPECS);
> }
> if (this.keyManagerFactory != null) {
> sanitazeOnMutation(SET_KEY_MGR_FAC);
> }
> break;
> {code}
> Before passing in the CallbackHandler and specifying which KINDS is applies to the ProtocolConnectionUtils call should first remove the duplicates from the configuration.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1969) Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1969?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse moved WFCORE-4975 to ELY-1969:
-----------------------------------------------
Project: WildFly Elytron (was: WildFly Core)
Key: ELY-1969 (was: WFCORE-4975)
Component/s: Authentication Client
(was: Security)
Fix Version/s: 1.12.0.CR4
(was: 12.0.0.Beta4)
> Where ModelControllerClient is initialised in process with CBH AuthenticationConfiguration takes priority.
> ----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1969
> URL: https://issues.redhat.com/browse/ELY-1969
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.12.0.CR4
>
>
> In ProtocolConnectionUtils we have the following code to pass in the provided CallbackHanldler: -
> {code:java}
> if (handler != null) {
> mergedConfiguration = mergedConfiguration.useCallbackHandler(handler, DEFAULT_CALLBACK_KINDS);
> }
> {code}
> However the AuthenticationClient performs the following sanitation of the specified KINDS: -
> {code:java}
> case SET_USER_CB_KINDS:
> // SANITAZE on above content
> if (this.principal != null) {
> sanitazeOnMutation(SET_PRINCIPAL);
> }
> if (this.credentialSource != null) {
> sanitazeOnMutation(SET_CRED_SOURCE);
> }
> if (this.setRealm != null) {
> sanitazeOnMutation(SET_REALM);
> }
> if (this.parameterSpecs != null) {
> sanitazeOnMutation(SET_PARAM_SPECS);
> }
> if (this.keyManagerFactory != null) {
> sanitazeOnMutation(SET_KEY_MGR_FAC);
> }
> break;
> {code}
> Before passing in the CallbackHandler and specifying which KINDS is applies to the ProtocolConnectionUtils call should first remove the duplicates from the configuration.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month