[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails
by Bartosz Andrzejewski (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Bartosz Andrzejewski edited comment on WFLY-5213 at 10/14/16 4:06 AM:
----------------------------------------------------------------------
Hello [~jmesnil],
I did it the same way you described, with one difference:
I'm using latest WildFly 10.1.0 and while configuring external-context I used "org.wildfly.extension.messaging-activemq" module, where i configured all the connectors.
It seems that JMS Context and Queue is injecting, but while I'm trying to use Context there is runtime exception (NameNotFoundException) - looking for comp/TransactionSynchronizationRegistry.
Any idea what that could be ? I would really appreciate any clues(I already spend few days on that).
A bit of stacktrace:
...
Caused by: javax.naming.NameNotFoundException: comp/TransactionSynchronizationRegistry -- service jboss.naming.context.java.comp.TransactionSynchronizationRegistry
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at org.apache.activemq.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:223)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.lookup(InjectedJMSContext.java:132)
... 74 more
was (Author: drzeyan):
Hello [~jmesnil],
I did it the same way you described, with one difference:
I'm using latest WildFly 10.1.0 and while configuring external-config I used "org.wildfly.extension.messaging-activemq" module, where i configured all the connectors.
It seems that JMS Context and Queue is injecting, but while I'm trying to use Context there is runtime exception (NameNotFoundException) - looking for comp/TransactionSynchronizationRegistry.
Any idea what that could be ? I would really appreciate any clues(I already spend few days on that).
A bit of stacktrace:
...
Caused by: javax.naming.NameNotFoundException: comp/TransactionSynchronizationRegistry -- service jboss.naming.context.java.comp.TransactionSynchronizationRegistry
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at org.apache.activemq.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:223)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.lookup(InjectedJMSContext.java:132)
... 74 more
> Injecting external context to Artemis fails
> -------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1327) Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
by Duncan Doyle (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1327?page=com.atlassian.jira.plugi... ]
Duncan Doyle reassigned DROOLS-1327:
------------------------------------
Assignee: Mario Fusco (was: Duncan Doyle)
> Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-1327
> URL: https://issues.jboss.org/browse/DROOLS-1327
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: JBoss BPM Suite 6.3.3.GA
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
>
> When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project.
> The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled.
> Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1327) Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
by Duncan Doyle (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1327?page=com.atlassian.jira.plugi... ]
Duncan Doyle commented on DROOLS-1327:
--------------------------------------
And the PR with the unit-test in jBPM: https://github.com/droolsjbpm/jbpm/pull/636
> Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-1327
> URL: https://issues.jboss.org/browse/DROOLS-1327
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: JBoss BPM Suite 6.3.3.GA
> Reporter: Duncan Doyle
> Assignee: Duncan Doyle
>
> When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project.
> The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled.
> Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1327) Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
by Duncan Doyle (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1327?page=com.atlassian.jira.plugi... ]
Duncan Doyle commented on DROOLS-1327:
--------------------------------------
PR: https://github.com/droolsjbpm/drools/pull/961
> Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-1327
> URL: https://issues.jboss.org/browse/DROOLS-1327
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: JBoss BPM Suite 6.3.3.GA
> Reporter: Duncan Doyle
> Assignee: Duncan Doyle
>
> When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project.
> The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled.
> Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7289) Adding ldap-key-store requires accessible ldap server
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7289?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7289:
-------------------------------
Priority: Critical (was: Major)
> Adding ldap-key-store requires accessible ldap server
> -----------------------------------------------------
>
> Key: WFLY-7289
> URL: https://issues.jboss.org/browse/WFLY-7289
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Critical
>
> Playing with ldap-key-store . What I consider very unconvenient is fact, that in moment of adding ldap-key-store, ldap server has to be running and accessible. Elytron ldap-realm does not need that. Doubt about legacy security realms. Is it possible to decouple that dependency and leave that check till first ldap-key-store usage?
> Steps to reproduce:
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/dir-context=a:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=a:add(dir-context=a, search-path="a")
> {
> "outcome" => "failed",
> "rolled-back" => true
> }
> {code}
> leads to exception in server log
> {code}
> 14:37:25,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
> "address" => [
> ("subsystem" => "elytron"),
> ("ldap-key-store" => "a")
> ],
> "operation" => "add",
> "search-path" => "a",
> "dir-context" => "a",
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE"
> }
> }]: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> at java.security.KeyStore.size(KeyStore.java:1271)
> at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> at java.security.KeyStore.size(KeyStore.java:1271)
> at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildTypes(AbstractModelResource.java:372)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:787)
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:520)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:758)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:709)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: Cannot parse url: undefined [Root exception is java.net.MalformedURLException: Invalid URI: undefined]
> at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:92)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:163)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> ... 39 more
> Caused by: java.net.MalformedURLException: Invalid URI: undefined
> at com.sun.jndi.toolkit.url.Uri.parse(Uri.java:199)
> at com.sun.jndi.toolkit.url.Uri.init(Uri.java:138)
> at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:82)
> ... 56 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7289) Adding ldap-key-store requires accessible ldap server
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7289?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-7289:
------------------------------------
And also could not start EAP if LDAP is down. Also seems like any CLI operation on resource (even read operation) cause LDAP server is touched.
{code}
[standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=c:read-attribute(name=new-item-path)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
"rolled-back" => true
}
{code}
Based on this findings going to raise priority.
> Adding ldap-key-store requires accessible ldap server
> -----------------------------------------------------
>
> Key: WFLY-7289
> URL: https://issues.jboss.org/browse/WFLY-7289
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
>
> Playing with ldap-key-store . What I consider very unconvenient is fact, that in moment of adding ldap-key-store, ldap server has to be running and accessible. Elytron ldap-realm does not need that. Doubt about legacy security realms. Is it possible to decouple that dependency and leave that check till first ldap-key-store usage?
> Steps to reproduce:
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/dir-context=a:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=a:add(dir-context=a, search-path="a")
> {
> "outcome" => "failed",
> "rolled-back" => true
> }
> {code}
> leads to exception in server log
> {code}
> 14:37:25,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
> "address" => [
> ("subsystem" => "elytron"),
> ("ldap-key-store" => "a")
> ],
> "operation" => "add",
> "search-path" => "a",
> "dir-context" => "a",
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE"
> }
> }]: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> at java.security.KeyStore.size(KeyStore.java:1271)
> at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> at java.security.KeyStore.size(KeyStore.java:1271)
> at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildTypes(AbstractModelResource.java:372)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:787)
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:520)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:758)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:709)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: Cannot parse url: undefined [Root exception is java.net.MalformedURLException: Invalid URI: undefined]
> at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:92)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:163)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> ... 39 more
> Caused by: java.net.MalformedURLException: Invalid URI: undefined
> at com.sun.jndi.toolkit.url.Uri.parse(Uri.java:199)
> at com.sun.jndi.toolkit.url.Uri.init(Uri.java:138)
> at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:82)
> ... 56 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7278) Unable to add trust-manager with ldap-key-store (classloading)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7278:
-----------------------------
Steps to Reproduce:
{code:java}
/subsystem=elytron/dir-context=DC1:add(url="ldap://localhost:10389/", authentication-level=none)
/subsystem=elytron/ldap-key-store=LKS1/:add(dir-context=DC1, search-path="ou=keystore,dc=elytron,dc=wildfly,dc=org")
/subsystem=elytron/trust-managers=MyTrustManager/:add(algorithm=SunX509, key-store=LKS1)
{code}
{code:java}
/subsystem=elytron/dir-context=DC1:add(url="ldap://localhost:10389/", authentication-level=none)
/subsystem=elytron/ldap-key-store=LKS1/:add(dir-context=DC2,search-path="ou=keystore,dc=example,dc=com",search-recursive=true)
/subsystem=elytron/ldap-key-store=LKS1:remove
{code}
was:
{code:java}
/subsystem=elytron/ldap-key-store=LKS1/:add(dir-context=Ldap1, search-path="ou=keystore,dc=elytron,dc=wildfly,dc=org")
/subsystem=elytron/trust-managers=MyTrustManager/:add(algorithm=SunX509, key-store=LKS1)
{code}
> Unable to add trust-manager with ldap-key-store (classloading)
> --------------------------------------------------------------
>
> Key: WFLY-7278
> URL: https://issues.jboss.org/browse/WFLY-7278
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> ... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> ... 28 more
> {code}
> Direct key-store aliases listing using works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1326) Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1326:
------------------------------------------
[~jlocker] go in SolveAllTurtleTest (the superclass) and play with the time spends... and this is where it sucks:
those turtle tests run 3 solvers (2 minutes, 5 minutes and 3 minutes for a total of 10 minutes):
{code}
Solution_ planningProblem = readPlanningProblem();
// Specifically use NON_INTRUSIVE_FULL_ASSERT instead of FULL_ASSERT to flush out bugs hidden by intrusiveness
// 1) NON_INTRUSIVE_FULL_ASSERT ASSERT to find CH bugs (but covers little ground)
planningProblem = buildAndSolve(solverFactory, EnvironmentMode.NON_INTRUSIVE_FULL_ASSERT, planningProblem, 2L);
// 2) FAST_ASSERT to run past CH into LS to find easy bugs (but covers much ground)
planningProblem = buildAndSolve(solverFactory, EnvironmentMode.FAST_ASSERT, planningProblem, 5L);
// 3) NON_INTRUSIVE_FULL_ASSERT ASSERT to find LS bugs (but covers little ground)
planningProblem = buildAndSolve(solverFactory, EnvironmentMode.NON_INTRUSIVE_FULL_ASSERT, planningProblem, 3L);
{code}
You need to mimic this output:
{code}
016-10-11 12:44:26,305 [main] INFO Opened: data/nurserostering/unsolved/long_hint01.xml
2016-10-11 12:44:26,592 [main] INFO Solving started: time spent (63), best score (-740init/0hard/-1580soft), environment mode (NON_INTRUSIVE_FULL_ASSERT), random (JDK with seed 0).
2016-10-11 12:46:26,542 [main] INFO Construction Heuristic phase (0) ended: time spent (120013), best score (-337init/0hard/-580soft), score calculation speed (167/sec), step total (403).
2016-10-11 12:46:26,543 [main] INFO Solving ended: time spent (120014), best score (-337init/0hard/-580soft), score calculation speed (167/sec), phase total (2), environment mode (NON_INTRUSIVE_FULL_ASSERT).
2016-10-11 12:46:26,882 [main] INFO Solving started: time spent (97), best score (-337init/0hard/-580soft), environment mode (FAST_ASSERT), random (JDK with seed 0).
2016-10-11 12:46:28,889 [main] INFO Construction Heuristic phase (0) ended: time spent (2104), best score (0hard/-175soft), score calculation speed (17127/sec), step total (337).
2016-10-11 12:51:26,785 [main] INFO Local Search phase (1) ended: time spent (300000), best score (0hard/-74soft), score calculation speed (6848/sec), step total (1233).
2016-10-11 12:51:26,785 [main] INFO Solving ended: time spent (300000), best score (0hard/-74soft), score calculation speed (6914/sec), phase total (2), environment mode (FAST_ASSERT).
2016-10-11 12:51:27,164 [main] INFO Solving started: time spent (157), best score (0hard/-74soft), environment mode (NON_INTRUSIVE_FULL_ASSERT), random (JDK with seed 0).
2016-10-11 12:51:27,165 [main] INFO Construction Heuristic phase (0) ended: time spent (158), best score (0hard/-74soft), score calculation speed (1000/sec), step total (0).
{code}
As this happens in the 3th solver, this isn't easy to reproduce, but it is possible: use stepCountLimit to get the exact same return state of the first solver and then the second solver and then just run the 3th solver for a long time (in case your cpu is slower than jenkins's), it should hit it.
> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
> Key: DROOLS-1326
> URL: https://issues.jboss.org/browse/DROOLS-1326
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtl...
> I 'll ask [~jlocker] to isolate.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7314) Elytron new-item-attributes are not serialized into standalone.xml
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7314?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6428 to WFLY-7314:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7314 (was: JBEAP-6428)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR6)
> Elytron new-item-attributes are not serialized into standalone.xml
> ------------------------------------------------------------------
>
> Key: WFLY-7314
> URL: https://issues.jboss.org/browse/WFLY-7314
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Critical
>
> {{new-item-attributes}} of {{ldap-key-store}} doesn't survive restart of server.
> See steps to reproduce for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months