[JBoss JIRA] (AS7-6104) jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6104?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-6104:
--------------------------------------
<maeste2> bstansberry: wprking on AS7-6104
<jbossbot> jira [AS7-6104] jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove() [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/AS7-6104
<maeste2> bstansberry: the problem is different there
<maeste2> bstansberry: it correctly fail operation
<maeste2> bstansberry: add operation
<maeste2> bstansberry: but when server is booting I see failure in log, but resource is added even if runtime part is rolled back
* hbraun has quit (Quit: hbraun)
<maeste2> bstansberry: it doesn't happen in normal mode
<maeste2> bstansberry: have you an explanation for that? Or is it something I have to seek in my code
<bstansberry> maeste2: the runtime part doesn't roll back on boot
<bstansberry> maeste2: I wish we did, but we don't rollback on runtime failures in boot
<maeste2> bstansberry: ok, so the problem is not in my code itself, it's a more general behaviour, right?
* pferraro (~paul(a)c-71-235-89-202.hsd1.ct.comcast.net) has joined #jboss-as7
* bstansberry is looking
<maeste2> bstansberry: because I'm failing in :remove action if the runtime of add isn't completed correctly
<maeste2> bstansberry: I get null for a service lookup
<bstansberry> maeste2: with the stack trace shown in the JIRA?
<maeste2> bstansberry: but in general we should not add the resource
<maeste2> bstansberry: yup exactly
<maeste2> bstansberry: users see the NPE for remove, because they are removing a resource not started correctly
<maeste2> bstansberry: in particular it's a driver refering to non existing module
<bstansberry> maeste2: ok, assign that to me; removeService shouldn't throw an NPE
* ssadeghi has quit (Ping timeout: 250 seconds)
<maeste2> bstansberry: oki, feel free to ping me if I can help in any way of course
<maeste2> bstansberry: can we discuss also AS7-5472
<jbossbot> jira [AS7-5472] unavailable datasource statistics [Open (Unresolved) Bug, Minor, Stefano Maestri] https://issues.jboss.org/browse/AS7-5472
<bstansberry> maeste2: the OSH should always check for null before invoking on the ServiceController, but you shouldn't have to null check before calling removeService
> jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6104
> URL: https://issues.jboss.org/browse/AS7-6104
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 7.1.1.Final
> Environment: Windows 7 Professional SP1
> Reporter: Raymond Naseef
> Assignee: Brian Stansberry
> Labels: jboss-as7, modules, postgresql
>
> NullPointerException during jboss-cli remove with command:
> jboss-cli --connect command="/subsystem=datasources/jdbc-driver=bop:remove"
> Console and log below.
> This happens when standalone.xml has XML entry for driver that does not exist (see "Steps to Reproduce"). I have also seen this happen in a case where the driver does exist; not sure how the latter happened, or how important that is.
> MS-DOS Console:
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: null",
> "rolled-back" => true
> }
> Server Log:
> 23:17:42,627 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 19) JBAS014612: Operation ("remove") failed - address: ([
> ("subsystem" => "datasources"),
> ("jdbc-driver" => "postgresql-driver")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.doRemove(OperationContextImpl.java:298) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.OperationContextImpl.removeService(OperationContextImpl.java:293) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.connector.subsystems.datasources.JdbcDriverRemove.performRuntime(JdbcDriverRemove.java:66)
> at org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:50) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:466) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:287) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:487) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
--
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
11 years, 9 months
[JBoss JIRA] (AS7-5584) Naming context read-only during SAR deployment
by Guy Kaisin (JIRA)
[ https://issues.jboss.org/browse/AS7-5584?page=com.atlassian.jira.plugin.s... ]
Guy Kaisin commented on AS7-5584:
---------------------------------
Hi all,
Still continuing to test/verify how to use mbean...
Here is now how I implement the bind/rebind:
<code>
private void rebind() throws NamingException
{
InitialContext rootCtx = new InitialContext();
Name fullName = rootCtx.getNameParser("").parse(getFullJndiName());
ServiceName servName=ServiceName.parse(getFullJndiName());
WritableServiceBasedNamingStore.pushOwner(servName);
try
{
logger.info("fullName=" + fullName+" -> rebind ...");
org.jboss.util.naming.NonSerializableFactory.rebind(fullName, sHelper, true);
logger.info("fullName=" + fullName+" -> rebind ok");
}
catch(NamingException ex)
{
ex.printStackTrace();
throw ex;
}
finally
{
WritableServiceBasedNamingStore.popOwner();
}
}
</code>
Like that, I don't have the 'context is read only' issue any more.
But I get another exception...
13:54:54,997 INFO [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) fullName=java:global/mid/be.pos
t.mid.dao.AddressDAO
13:54:55,012 INFO [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) fullName=java:global/mid/be.pos
t.mid.dao.AddressDAO -> rebind ...
13:54:55,013 ERROR [stderr] (MSC service thread 1-2) javax.naming.NamingException: Failed to bind [Reference Class Name:
be.post.common.servicelocator.helper.ServiceHelper
13:54:55,014 ERROR [stderr] (MSC service thread 1-2) Type: nns
13:54:55,014 ERROR [stderr] (MSC service thread 1-2) Content: java:global/mid/be.post.mid.dao.AddressDAO
13:54:55,014 ERROR [stderr] (MSC service thread 1-2) ] at location [service jboss.naming.context.java.global.mid."be.pos
t.mid.dao.AddressDAO"] [Root exception is java.lang.NullPointerException]
13:54:55,015 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.util.NamingUtils.namingException(NamingUt
ils.java:151)
13:54:55,061 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(Writ
ableServiceBasedNamingStore.java:80)
13:54:55,066 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(Wr
itableServiceBasedNamingStore.java:95)
13:54:55,066 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:2
61)
13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.InitialContext.rebind(InitialContext.java
:158)
13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:2
69)
13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at javax.naming.InitialContext.rebind(InitialContext.java:408)
13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerial
izableFactory.java:185)
13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerial
izableFactory.java:250)
13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at be.post.common.servicebinder.JndiBinder.rebind(JndiBinder.jav
a:72)
13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at be.post.common.servicebinder.JndiBinder.startService(JndiBind
er.java:52)
13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(Servi
ceMBeanSupport.java:250)
13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSuppor
t.java:158)
13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(Serv
iceMBeanSupport.java:229)
13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSuppo
rt.java:154)
13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.postRegister(ServiceMBea
nSupport.java:364)
13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.mbeanserver.MBeanSupport.postRegister(MBeanSuppor
t.java:192)
13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postReg
isterInvoke(DefaultMBeanServerInterceptor.java:1035)
13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
rDynamicMBean(DefaultMBeanServerInterceptor.java:974)
13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
rObject(DefaultMBeanServerInterceptor.java:917)
13:54:55,072 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
rMBean(DefaultMBeanServerInterceptor.java:312)
13:54:55,072 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBean
Server.java:482)
13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.reg
isterMBean(PluggableMBeanServerImpl.java:551)
13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(Plugg
ableMBeanServerImpl.java:319)
13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistra
tionService.java:90)
13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startSe
rvice(ServiceControllerImpl.java:1811)
13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(Ser
viceControllerImpl.java:1746)
13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Thread
PoolExecutor.java:886)
13:54:55,075 ERROR [stderr] (MSC service thread 1-2) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool
Executor.java:908)
13:54:55,075 ERROR [stderr] (MSC service thread 1-2) at java.lang.Thread.run(Thread.java:662)
13:54:55,076 ERROR [stderr] (MSC service thread 1-2) Caused by: java.lang.NullPointerException
13:54:55,076 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(Writ
ableServiceBasedNamingStore.java:77)
13:54:55,076 ERROR [stderr] (MSC service thread 1-2) ... 28 more
13:54:55,076 WARN [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) Starting failed mid.services.da
o:service=AddressDAOMBean: javax.naming.NamingException: Failed to bind [Reference Class Name: be.post.common.serviceloc
ator.helper.ServiceHelper
Type: nns
Content: java:global/mid/be.post.mid.dao.AddressDAO
] at location [service jboss.naming.context.java.global.mid."be.post.mid.dao.AddressDAO"] [Root exception is java.lang.N
ullPointerException]
at org.jboss.as.naming.util.NamingUtils.namingException(NamingUtils.java:151)
at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:80)
at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:95)
at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:261)
at org.jboss.as.naming.InitialContext.rebind(InitialContext.java:158)
at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:269)
at javax.naming.InitialContext.rebind(InitialContext.java:408) [rt.jar:1.6.0_25]
at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:185)
at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:250)
at be.post.common.servicebinder.JndiBinder.rebind(JndiBinder.java:72)
at be.post.common.servicebinder.JndiBinder.startService(JndiBinder.java:52)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:250)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:158)
at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:229)
at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:154)
at org.jboss.system.ServiceMBeanSupport.postRegister(ServiceMBeanSupport.java:364)
at com.sun.jmx.mbeanserver.MBeanSupport.postRegister(MBeanSupport.java:192) [rt.jar:1.6.0_25]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1
035) [rt.jar:1.6.0_25]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java
:974) [rt.jar:1.6.0_25]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
[rt.jar:1.6.0_25]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) [
rt.jar:1.6.0_25]
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) [rt.jar:1.6.0_25]
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:551) [j
boss-as-jmx-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:319) [jboss-as-jmx-7.2.
0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:90) [jboss-as-jmx-7.2.0.Alpha1-
SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-ms
c-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.G
A.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_25]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_25]
Caused by: java.lang.NullPointerException
at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:77)
... 28 more
13:54:55,087 ERROR [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) javax.naming.NamingException: F
ailed to bind [Reference Class Name: be.post.common.servicelocator.helper.ServiceHelper
Type: nns
Content: java:global/mid/be.post.mid.dao.AddressDAO
] at location [service jboss.naming.context.java.global.mid."be.post.mid.dao.AddressDAO"] [Root exception is java.lang.N
ullPointerException]
I use a jboss-service.xml file, containing the following:
<mbean name="mid.services.dao:service=AddressDAOMBean"
code="be.post.common.servicebinder.DaoJndiBinder">
<attribute name="JndiName">be.post.mid.dao.AddressDAO</attribute>
<attribute name="DataSourceJndiName">java:MIDCoreOracleDS</attribute>
<attribute name="InterfaceClass">be.post.mid.dao.AddressDAO</attribute>
<attribute name="ImplementationClass">be.post.mid.dao.oracle.AddressOracle</attribute>
</mbean>
I could identify the line giving the exception:
// add the service name to runtime bindings management service, which on stop releases the services.
final Set<ServiceName> duBindingReferences = (Set<ServiceName>) getServiceRegistry().getService(JndiNamingDependencyProcessor.serviceName(deploymentUnitServiceName)).getValue();
But what is the root cause of it?
any suggestion?
thanks a lot...
> Naming context read-only during SAR deployment
> ----------------------------------------------
>
> Key: AS7-5584
> URL: https://issues.jboss.org/browse/AS7-5584
> Project: Application Server 7
> Issue Type: Bug
> Components: POJO
> Affects Versions: 7.1.1.Final
> Reporter: Philippe Marschall
> Assignee: Philippe Marschall
> Fix For: 7.2.0.Alpha1
>
>
> During the #start() #stop() method of a legacy SAR the naming context is read only. The problem seems to be that {{org.jboss.as.service.AbstractService.invokeLifecycleMethod(Method)}} only sets the thread context class loader and does not do {{WritableServiceBasedNamingStore.pushOwner}}
> http://stackoverflow.com/questions/12419234/how-to-bind-an-object-to-jndi...
--
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
11 years, 9 months
[JBoss JIRA] (SECURITY-712) Variable expansion and Vault are not supported in the module-option of the LdapRolesMappingProvider mapping-module
by guillaume cornet (JIRA)
guillaume cornet created SECURITY-712:
-----------------------------------------
Summary: Variable expansion and Vault are not supported in the module-option of the LdapRolesMappingProvider mapping-module
Key: SECURITY-712
URL: https://issues.jboss.org/browse/SECURITY-712
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: PicketBox_v4_0_9.Final
Environment: RHEL 6.3
Reporter: guillaume cornet
Assignee: Anil Saldhana
When using LdapRolesMappingProviders mapping-module, I don't want to put the bindCredential/password in clear in the configuration file.
So I'm trying to use vault, this way :
<mapping-module code="org.jboss.security.mapping.providers.role.LdapRolesMappingProvider" type="role">
<module-option name="java.naming.provider.url" value="ldap://192.168.122.101:389" />
<module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" />
<module-option name="java.naming.security.authentication" value="simple" />
<module-option name="bindDN" value="CN=Administrator,CN=users,DC=cloud,DC=local" />
<module-option name="bindCredential" value="${VAULT::AD::addspass::YTgyMDI0ZjUtOWQwZi00MWZlLTkzMjMtMTM0YzRjZTY3ZWZmTElORV9CUkVBS3ZhdWx0}" />
<module-option name="rolesCtxDN" value="CN=users,DC=cloud,DC=local" />
<module-option name="roleFilter" value="(userPrincipalName={0})" />
<module-option name="roleAttributeID" value="memberOf" />
<module-option name="roleNameAttributeID" value="CN" />
<module-option name="roleAttributeIsDN" value="true" />
<module-option name="parseRoleNameFromDN" value="false" />
<module-option name="roleRecursion" value="0" />
<module-option name="searchScope" value="ONELEVEL_SCOPE" />
</mapping-module>
Unfortunatly, with this configuration, I cannot connect anymore to my Active Directory Directory Service....
I get the following error message in the jboss log :
14:59:35,019 ERROR [org.jboss.security.mapping.providers.role.LdapRolesMappingProvider] (http-/0.0.0.0:8080-1) Error connecting to LDAP server: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3087) [rt.jar:1.7.0_09-icedtea]
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033) [rt.jar:1.7.0_09-icedtea]
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2835) [rt.jar:1.7.0_09-icedtea]
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749) [rt.jar:1.7.0_09-icedtea]
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_09-icedtea]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_09-icedtea]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_09-icedtea]
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_09-icedtea]
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_09-icedtea]
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_09-icedtea]
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_09-icedtea]
at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_09-icedtea]
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_09-icedtea]
at org.jboss.security.mapping.providers.role.LdapRolesMappingProvider.constructInitialLdapContext(LdapRolesMappingProvider.java:256)
at org.jboss.security.mapping.providers.role.LdapRolesMappingProvider.performMapping(LdapRolesMappingProvider.java:192)
at org.jboss.security.mapping.providers.role.LdapRolesMappingProvider.performMapping(LdapRolesMappingProvider.java:53)
at org.jboss.security.mapping.MappingContext.performMapping(MappingContext.java:54)
at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:397)
at org.jboss.security.plugins.JBossAuthorizationManager.getSubjectRoles(JBossAuthorizationManager.java:324)
at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:230)
at org.jboss.security.negotiation.NegotiationAuthenticator.authenticate(NegotiationAuthenticator.java:187)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:455)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
I do some remote debug and I beleive that the vault expression is not resolved ....
package org.jboss.security.mapping.providers.role, class LdapRolesMappingProvider, method init(Map<String, Object> options).
This method don't perform any Variable expansion and nor Vault expansion.
--
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
11 years, 9 months
[JBoss JIRA] (SECURITY-711) LdapExtAdLoginModule proposal for inclusion
by Péter Radics (JIRA)
[ https://issues.jboss.org/browse/SECURITY-711?page=com.atlassian.jira.plug... ]
Péter Radics updated SECURITY-711:
----------------------------------
Attachment: picketbox-r362-LdapExtAdLoginModule.patch
patch that adds LdapExtAdLoginModule
> LdapExtAdLoginModule proposal for inclusion
> -------------------------------------------
>
> Key: SECURITY-711
> URL: https://issues.jboss.org/browse/SECURITY-711
> Project: PicketBox
> Issue Type: Patch
> Security Level: Public(Everyone can see)
> Components: PicketBox, Security SPI
> Affects Versions: PicketBox_4_0_14.Final
> Environment: jboss7, active directory authentication
> Reporter: Péter Radics
> Assignee: Anil Saldhana
> Priority: Minor
> Labels: LdapExtLoginModule, active-directory, security
> Attachments: picketbox-r362-LdapExtAdLoginModule.patch
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Please consider including the attached LdapExtAdLoginModule into the official release. This login module is based on r362 of LdapExtLoginModule, but it's better suited for deeply nested Active Directory domains: it only uses one search for the userDN then it's resolving the roles recursively by querying attributes on DNs only. (as a side-effect, it doesn't trigger AS7-5737)
--
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
11 years, 9 months
[JBoss JIRA] (SECURITY-711) LdapExtAdLoginModule proposal for inclusion
by Péter Radics (JIRA)
Péter Radics created SECURITY-711:
-------------------------------------
Summary: LdapExtAdLoginModule proposal for inclusion
Key: SECURITY-711
URL: https://issues.jboss.org/browse/SECURITY-711
Project: PicketBox
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: PicketBox, Security SPI
Affects Versions: PicketBox_4_0_14.Final
Environment: jboss7, active directory authentication
Reporter: Péter Radics
Assignee: Anil Saldhana
Priority: Minor
Attachments: picketbox-r362-LdapExtAdLoginModule.patch
Please consider including the attached LdapExtAdLoginModule into the official release. This login module is based on r362 of LdapExtLoginModule, but it's better suited for deeply nested Active Directory domains: it only uses one search for the userDN then it's resolving the roles recursively by querying attributes on DNs only. (as a side-effect, it doesn't trigger AS7-5737)
--
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
11 years, 9 months
[JBoss JIRA] (SECURITY-710) Vault : if the storepass is not equal to the keypass, the exception "PB00019: Processing Failed:Unable to get Keystore" is raised
by guillaume cornet (JIRA)
guillaume cornet created SECURITY-710:
-----------------------------------------
Summary: Vault : if the storepass is not equal to the keypass, the exception "PB00019: Processing Failed:Unable to get Keystore" is raised
Key: SECURITY-710
URL: https://issues.jboss.org/browse/SECURITY-710
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: guillaume cornet
Assignee: Anil Saldhana
vault.sh terminates on error "Exception encountered:PB00019: Processing Failed:Unable to get Keystore:" when the storepass and the keypass are differents.
I beleive this behavior is caused by a bug in the method org.picketbox.plugins.vault.PicketBoxSecurityVault.init(Map<String, Object> options).
I'm using picketbox 4.0.9, which contains the following code :
package org.picketbox.plugins.vault;
...
class PicketBoxSecurityVault ... {
...
public void init(Map<String, Object> options) throws SecurityVaultException
{
...
keystore = KeyStoreUtil.getKeyStore(keystoreURL, keystorePass.toCharArray());
keypair = KeyStoreUtil.getPrivateKey(keystore, alias, keystorePass.toCharArray());
...
}
...
As you can see, this code loads the store (e.g. 'getKeyStore()') and the key (e.g. 'getPrivateKey()') with the same password (e.g. 'keystorePass') ...
--
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
11 years, 9 months
[JBoss JIRA] (AS7-6144) Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/AS7-6144?page=com.atlassian.jira.plugin.s... ]
Scott Marlow closed AS7-6144.
-----------------------------
> Fallback for JBossAppServerJtaPlatform.locateUserTransaction() to look at "java:jboss" if "java:comp" not available
> -------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6144
> URL: https://issues.jboss.org/browse/AS7-6144
> Project: Application Server 7
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Environment: JBoss AS 7.1.2.Final, Hibernate 4.1.2.Final
> Reporter: Marek Posolda
> Assignee: Scott Marlow
>
> Normally UserTransaction is available in JBoss via JNDI lookup to "java:comp/UserTransaction" . But sometimes this approach does not work (For example if we have custom worker threads in our application or we are starting our AS7 deployment with custom MSC thread before "java:comp" context is available to JNDI)
> So it may be good to fallback to "java:jboss/UserTransaction", which is available in JBoss AS7 even from custom threads.
> Is it possible to change "org.jboss.as.jpa.hibernate4.JBossAppServerJtaPlatform" or "org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform" to have method locateUserTransaction() similar to this?:
> {code}
> public static final String AS7_NEW_UT_NAME = "java:jboss/UserTransaction";
> @Override
> protected UserTransaction locateUserTransaction() {
> try {
> return (UserTransaction) jndiService().locate(UT_NAME);
> }
> catch(JndiException jndiException) {
> return (UserTransaction) jndiService().locate(AS7_NEW_UT_NAME);
> }
> }
> {code}
--
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
11 years, 9 months