[JBoss JIRA] (DROOLS-474) java.lang.IllegalStateException: There's already another KieContainer created from a different ClassLoader
by Charles Moulliard (JIRA)
[ https://issues.jboss.org/browse/DROOLS-474?page=com.atlassian.jira.plugin... ]
Charles Moulliard commented on DROOLS-474:
------------------------------------------
Miss the most important thing -->
Caused by: java.lang.IllegalStateException: There's already another KieContainer created from a different ClassLoader
at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:74)
at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:59)
at org.kie.aries.blueprint.factorybeans.KieObjectsResolver.init(KieObjectsResolver.java:47)
at org.kie.aries.blueprint.factorybeans.KieObjectsResolver.<init>(KieObjectsResolver.java:42)
at org.kie.aries.blueprint.factorybeans.KieObjectsFactoryBean.createKieSession(KieObjectsFactoryBean.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_51]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_51]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_51]
at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:313)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> java.lang.IllegalStateException: There's already another KieContainer created from a different ClassLoader
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-474
> URL: https://issues.jboss.org/browse/DROOLS-474
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta3
> Reporter: Charles Moulliard
> Assignee: Mark Proctor
>
> The following error/warn is generated when we deploy on Karaf the feature
> drools-decision-kie-blueprint-camel-example
> using kie-aries-blueprint
> {code}
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: kie://ksession1?action=insertBody due to: Cannot lookup: ksession1 from registry: org.apache.camel.blueprint.BlueprintContainerRegistry@5d13728f with expected type: interface org.kie.api.runtime.CommandExecutor due: Error when instantiating bean ksession1 of class class org.kie.aries.blueprint.factorybeans.KieObjectsFactoryBean
> at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:479)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.util.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:50)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.model.RouteDefinition.resolveEndpoint(RouteDefinition.java:186)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:108)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:114)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.model.SendDefinition.resolveEndpoint(SendDefinition.java:61)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.model.SendDefinition.createProcessor(SendDefinition.java:55)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:461)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:179)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:870)[322:org.apache.camel.camel-core:2.10.3]
> ... 48 more
> Caused by: org.apache.camel.NoSuchBeanException: Cannot lookup: ksession1 from registry: org.apache.camel.blueprint.BlueprintContainerRegistry@5d13728f with expected type: interface org.kie.api.runtime.CommandExecutor due: Error when instantiating bean ksession1 of class class org.kie.aries.blueprint.factorybeans.KieObjectsFactoryBean
> at org.apache.camel.impl.CompositeRegistry.lookup(CompositeRegistry.java:58)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.impl.PropertyPlaceholderDelegateRegistry.lookup(PropertyPlaceholderDelegateRegistry.java:62)[322:org.apache.camel.camel-core:2.10.3]
> at org.kie.camel.component.KieEndpoint.configure(KieEndpoint.java:152)[384:org.kie.camel:6.1.0.20140429-1736]
> at org.kie.camel.component.KieEndpoint.<init>(KieEndpoint.java:114)[384:org.kie.camel:6.1.0.20140429-1736]
> at org.kie.camel.component.KieComponent.createEndpoint(KieComponent.java:56)[384:org.kie.camel:6.1.0.20140429-1736]
> at org.apache.camel.impl.DefaultComponent.createEndpoint(DefaultComponent.java:91)[322:org.apache.camel.camel-core:2.10.3]
> at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:461)[322:org.apache.camel.camel-core:2.10.3]
> ... 57 more
> Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean ksession1 of class class org.kie.aries.blueprint.factorybeans.KieObjectsFactoryBean
> at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:315)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_51]
> at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:230)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:145)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.getComponentInstance(BlueprintContainerImpl.java:754)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.camel.blueprint.BlueprintContainerRegistry.lookup(BlueprintContainerRegistry.java:47)[330:org.apache.camel.camel-blueprint:2.10.3]
> at org.apache.camel.impl.CompositeRegistry.lookup(CompositeRegistry.java:49)[322:org.apache.camel.camel-core:2.10.3]
> ... 63 more
> Caused by: java.lang.IllegalStateException: There's already another KieContainer created from a different ClassLoader
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:74)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:59)
> at org.kie.aries.blueprint.factorybeans.KieObjectsResolver.init(KieObjectsResolver.java:47)[386:org.kie.aries.blueprint:6.1.0.20140429-1736]
> at org.kie.aries.blueprint.factorybeans.KieObjectsResolver.<init>(KieObjectsResolver.java:42)[386:org.kie.aries.blueprint:6.1.0.20140429-1736]
> at org.kie.aries.blueprint.factorybeans.KieObjectsFactoryBean.createKieSession(KieObjectsFactoryBean.java:70)[386:org.kie.aries.blueprint:6.1.0.20140429-1736]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_51]
> at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:313)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
> ... 74 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years
[JBoss JIRA] (WFLY-3306) Inconsistent responses between read-children-types and read-children-names or read-children-resources
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-3306:
--------------------------------------
Summary: Inconsistent responses between read-children-types and read-children-names or read-children-resources
Key: WFLY-3306
URL: https://issues.jboss.org/browse/WFLY-3306
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.1.0.CR1, 8.0.0.CR1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 9.0.0.CR1
The read-children-types op is implemented by reading the names of the NodeSubregistry objects in the target resource's ManagementResourceRegistration. The read-children-names and read-children-resources ops are implemented by reading the full PathElement of registered child MRRs.
It's possible these two can get out of sync, as a NodeSubregistry can be added in order to support a submodel, but such subregistries aren't removed if all children are removed. This manifests itself in EAP 6 with the 'server' child type. See https://bugzilla.redhat.com/show_bug.cgi?id=1093030. (Note WF should not have this specific problem, as WF registers a generic MRR for 'server'.)
Fix is for GlobalOperationHandlers.getChildAddresses() to include an entry with an empty value for any valid child type. This will ensure the responses are consistent.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years
[JBoss JIRA] (DROOLS-474) java.lang.IllegalStateException: There's already another KieContainer created from a different ClassLoader
by Charles Moulliard (JIRA)
Charles Moulliard created DROOLS-474:
----------------------------------------
Summary: java.lang.IllegalStateException: There's already another KieContainer created from a different ClassLoader
Key: DROOLS-474
URL: https://issues.jboss.org/browse/DROOLS-474
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0.Beta3
Reporter: Charles Moulliard
Assignee: Mark Proctor
The following error/warn is generated when we deploy on Karaf the feature
drools-decision-kie-blueprint-camel-example
using kie-aries-blueprint
{code}
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: kie://ksession1?action=insertBody due to: Cannot lookup: ksession1 from registry: org.apache.camel.blueprint.BlueprintContainerRegistry@5d13728f with expected type: interface org.kie.api.runtime.CommandExecutor due: Error when instantiating bean ksession1 of class class org.kie.aries.blueprint.factorybeans.KieObjectsFactoryBean
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:479)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.util.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:50)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.model.RouteDefinition.resolveEndpoint(RouteDefinition.java:186)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:108)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:114)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.model.SendDefinition.resolveEndpoint(SendDefinition.java:61)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.model.SendDefinition.createProcessor(SendDefinition.java:55)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:461)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:179)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:870)[322:org.apache.camel.camel-core:2.10.3]
... 48 more
Caused by: org.apache.camel.NoSuchBeanException: Cannot lookup: ksession1 from registry: org.apache.camel.blueprint.BlueprintContainerRegistry@5d13728f with expected type: interface org.kie.api.runtime.CommandExecutor due: Error when instantiating bean ksession1 of class class org.kie.aries.blueprint.factorybeans.KieObjectsFactoryBean
at org.apache.camel.impl.CompositeRegistry.lookup(CompositeRegistry.java:58)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.impl.PropertyPlaceholderDelegateRegistry.lookup(PropertyPlaceholderDelegateRegistry.java:62)[322:org.apache.camel.camel-core:2.10.3]
at org.kie.camel.component.KieEndpoint.configure(KieEndpoint.java:152)[384:org.kie.camel:6.1.0.20140429-1736]
at org.kie.camel.component.KieEndpoint.<init>(KieEndpoint.java:114)[384:org.kie.camel:6.1.0.20140429-1736]
at org.kie.camel.component.KieComponent.createEndpoint(KieComponent.java:56)[384:org.kie.camel:6.1.0.20140429-1736]
at org.apache.camel.impl.DefaultComponent.createEndpoint(DefaultComponent.java:91)[322:org.apache.camel.camel-core:2.10.3]
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:461)[322:org.apache.camel.camel-core:2.10.3]
... 57 more
Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: Error when instantiating bean ksession1 of class class org.kie.aries.blueprint.factorybeans.KieObjectsFactoryBean
at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:315)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_51]
at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BlueprintRepository.createInstance(BlueprintRepository.java:230)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BlueprintRepository.create(BlueprintRepository.java:145)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.getComponentInstance(BlueprintContainerImpl.java:754)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.camel.blueprint.BlueprintContainerRegistry.lookup(BlueprintContainerRegistry.java:47)[330:org.apache.camel.camel-blueprint:2.10.3]
at org.apache.camel.impl.CompositeRegistry.lookup(CompositeRegistry.java:49)[322:org.apache.camel.camel-core:2.10.3]
... 63 more
Caused by: java.lang.IllegalStateException: There's already another KieContainer created from a different ClassLoader
at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:74)
at org.drools.compiler.kie.builder.impl.KieServicesImpl.getKieClasspathContainer(KieServicesImpl.java:59)
at org.kie.aries.blueprint.factorybeans.KieObjectsResolver.init(KieObjectsResolver.java:47)[386:org.kie.aries.blueprint:6.1.0.20140429-1736]
at org.kie.aries.blueprint.factorybeans.KieObjectsResolver.<init>(KieObjectsResolver.java:42)[386:org.kie.aries.blueprint:6.1.0.20140429-1736]
at org.kie.aries.blueprint.factorybeans.KieObjectsFactoryBean.createKieSession(KieObjectsFactoryBean.java:70)[386:org.kie.aries.blueprint:6.1.0.20140429-1736]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_51]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_51]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_51]
at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:313)[8:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
... 74 more
{code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years
[JBoss JIRA] (WFLY-3305) :deploy after :undeploy is broken
by Emmanuel Hugonnet (JIRA)
Emmanuel Hugonnet created WFLY-3305:
---------------------------------------
Summary: :deploy after :undeploy is broken
Key: WFLY-3305
URL: https://issues.jboss.org/browse/WFLY-3305
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Server
Affects Versions: 8.1.0.CR1
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
When redeploying via :deploy an application previously undeployed via :undeploy, the deployment is deployed, then undeployed, then deployed again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3067:
-----------------------------------------------
Rostislav Svoboda <rsvoboda(a)redhat.com> changed the Status of [bug 1079084|https://bugzilla.redhat.com/show_bug.cgi?id=1079084] from ON_QA to VERIFIED
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
> Key: WFLY-3067
> URL: https://issues.jboss.org/browse/WFLY-3067
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.0.0.Final
> Reporter: Kyle Lape
> Assignee: Jim Ma
> Fix For: 8.1.0.CR1
>
>
> Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3048:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1069127|https://bugzilla.redhat.com/show_bug.cgi?id=1069127] from ON_QA to VERIFIED
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.1.0.CR1
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" />
> <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
> ...
> </ldap>
> </authentication>
> <authorization map-groups-to-roles="false">
> <ldap connection="...">
> ...
> </ldap>
> </authorization>
> </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3048:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from ON_QA to VERIFIED
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.1.0.CR1
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" />
> <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
> ...
> </ldap>
> </authentication>
> <authorization map-groups-to-roles="false">
> <ldap connection="...">
> ...
> </ldap>
> </authorization>
> </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years