[JBoss JIRA] (WFCORE-125) Security realm cache definitions not possible for LDAP prinicipal to group group loading.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-125:
---------------------------------------
Summary: Security realm cache definitions not possible for LDAP prinicipal to group group loading.
Key: WFCORE-125
URL: https://issues.jboss.org/browse/WFCORE-125
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Security
Affects Versions: 1.0.0.Alpha8
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Alpha9
{quote}
It's not possible to configure LDAP cache in security realms under "authorization=ldap/group-search=principal-to-group"
Possible reason:
The LdapCacheResourceDefinition is not registered under the org.jboss.as.domain.management.security.PrincipalToGroupResourceDefinition
When I try to add the cache configuration manually to standalone.xml, server doesn't start and reports:
15:23:44,619 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014629: No resource definition is registered for address [
("core-service" => "management"),
("security-realm" => "JBossTest"),
("authorization" => "ldap"),
("group-search" => "principal-to-group"),
("cache" => "by-search-time")
]
15:23:44,621 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-794) javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-794:
----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 958166|https://bugzilla.redhat.com/show_bug.cgi?id=958166] from ON_QA to VERIFIED
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-794
> URL: https://issues.jboss.org/browse/WFLY-794
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Reporter: Alex Corvino
> Assignee: Eduardo Martins
> Labels: investigation_required
> Fix For: 9.0.0.Alpha1
>
> Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown.
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final).
> Note that this behavior is NOT seen when connecting to another JBoss server.
> Full stack trace:
> {code}
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> ... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> ... 37 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (DROOLS-610) drools-worker-2 thread blocked and the main program blocks
by Nathalie ravenel (JIRA)
[ https://issues.jboss.org/browse/DROOLS-610?page=com.atlassian.jira.plugin... ]
Nathalie ravenel commented on DROOLS-610:
-----------------------------------------
In fact, after modifying the value in the working memory, how can we be sure that the appropriated rule is fired ?
De : Mario Fusco (JIRA) [mailto:issues@jboss.org]
Envoyé : jeudi 25 septembre 2014 09:29
À : RAVENEL Nathalie 161957
Objet : [JBoss JIRA] (DROOLS-610) drools-worker-2 thread blocked and the main program blocks
[https://developer.jboss.org/gravatar/9eafc29df96e6aaf4a3eb4c0209086ae?d=m...]
Mario Fusco<https://issues.jboss.org/secure/ViewProfile.jspa?name=mfusco> commented on [Bug] DROOLS-610<https://issues.jboss.org/browse/DROOLS-610>
Re: drools-worker-2 thread blocked and the main program blocks<https://issues.jboss.org/browse/DROOLS-610>
It's hard to tell just looking at that method and missing the big picture. If you want to keep using that method as it is from both your code and from inside a rule consequence I suggest to add a boolean to its list of arguments more or less as it follows:
public void modifier_element(String nom_slot, String valeur, boolean inConsequence) {
// do stuff
if (!inConsequence) {
this.session.fireAllRules();
}
// do other stuff
}
and invoke that method passing true when you call it from a consequence and false when you call it from your code.
Makes sense?
[Add Comment]<https://issues.jboss.org/browse/DROOLS-610#add-comment>
Add Comment<https://issues.jboss.org/browse/DROOLS-610#add-comment>
This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1)
[Atlassian logo]
> drools-worker-2 thread blocked and the main program blocks
> ----------------------------------------------------------
>
> Key: DROOLS-610
> URL: https://issues.jboss.org/browse/DROOLS-610
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Environment: linux
> Reporter: Nathalie ravenel
> Assignee: Mario Fusco
> Attachments: blocked.PNG, drools-worker-2.PNG, image001.jpg, image001.jpg, main thread.PNG, pool-1-thread1.PNG
>
>
> Running our program, we got some deadlock on one thread (drools-worker-2). We investigated the problem using java memory control. The thread is blocked and the program also. The stack traces was registered for the different threads. The last trace for the thread was : org.drools.core.common.SynchronizedLeftTuplesSets.takeAll.
> There are 1111 Blocked count on one DeadLock on the thread.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBJCA-1181) Recovery is not run for XA datasource which does not define password under <security>
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1181?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1181:
------------------------------------------------
Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1107991|https://bugzilla.redhat.com/show_bug.cgi?id=1107991] from ASSIGNED to CLOSED
> Recovery is not run for XA datasource which does not define password under <security>
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1181
> URL: https://issues.jboss.org/browse/JBJCA-1181
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Fix For: 1.0.27.Final, 1.2.0.Beta4
>
> Attachments: server.log
>
>
> If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database.
> When you define just:
> {code}
> <security>
> <user-name>crashrec</user-name>
> </security>
> {code}
> and database is set to not require password - e.g. for postgres
> vim /var/lib/pgsql/data/pg_hba.conf
> you define connection with 'trust'
> host all all 127.0.0.1/32 trust
> Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run
> {code}
> 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS
> 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS
> {code}
> Whole configuration of xa-datasource used:
> {code}
> <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true">
> <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgres</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>50</max-pool-size>
> </xa-pool>
> <security>
> <user-name>crashrec</user-name>
> </security>
> <recovery>
> <!--
> <recover-credential>
> <user-name>crashrec</user-name>
> </recover-credential>
> -->
> </recovery>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> <timeout>
> <blocking-timeout-millis>30000</blocking-timeout-millis>
> <idle-timeout-minutes>15</idle-timeout-minutes>
> </timeout>
> <statement>
> <prepared-statement-cache-size>75</prepared-statement-cache-size>
> </statement>
> </xa-datasource>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBJCA-1181) Recovery is not run for XA datasource which does not define password under <security>
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1181?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1181:
------------------------------------------------
Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1107991|https://bugzilla.redhat.com/show_bug.cgi?id=1107991] from ASSIGNED to CLOSED
> Recovery is not run for XA datasource which does not define password under <security>
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1181
> URL: https://issues.jboss.org/browse/JBJCA-1181
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Fix For: 1.0.27.Final, 1.2.0.Beta4
>
> Attachments: server.log
>
>
> If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database.
> When you define just:
> {code}
> <security>
> <user-name>crashrec</user-name>
> </security>
> {code}
> and database is set to not require password - e.g. for postgres
> vim /var/lib/pgsql/data/pg_hba.conf
> you define connection with 'trust'
> host all all 127.0.0.1/32 trust
> Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run
> {code}
> 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS
> 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS
> {code}
> Whole configuration of xa-datasource used:
> {code}
> <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true">
> <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgres</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>50</max-pool-size>
> </xa-pool>
> <security>
> <user-name>crashrec</user-name>
> </security>
> <recovery>
> <!--
> <recover-credential>
> <user-name>crashrec</user-name>
> </recover-credential>
> -->
> </recovery>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> <timeout>
> <blocking-timeout-millis>30000</blocking-timeout-millis>
> <idle-timeout-minutes>15</idle-timeout-minutes>
> </timeout>
> <statement>
> <prepared-statement-cache-size>75</prepared-statement-cache-size>
> </statement>
> </xa-datasource>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3895) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}
by Thomas Diesler (JIRA)
Thomas Diesler created WFLY-3895:
------------------------------------
Summary: Blocking request failed HttpServerExchange{ POST /fabric/jolokia}
Key: WFLY-3895
URL: https://issues.jboss.org/browse/WFLY-3895
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.1.0.Final
Reporter: Thomas Diesler
Assignee: Stuart Douglas
This happens with an Http POST request for a Jolokia MBean operation.
Attribute reads seem to work.
{code}
10:28:10,823 ERROR [io.undertow.request] (default task-3) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1952)
at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:146)
at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:588)
at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1404)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:193)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (DROOLS-612) Create a project wizard can finish with error
by Tomáš Sedmík (JIRA)
Tomáš Sedmík created DROOLS-612:
-----------------------------------
Summary: Create a project wizard can finish with error
Key: DROOLS-612
URL: https://issues.jboss.org/browse/DROOLS-612
Project: Drools
Issue Type: Bug
Affects Versions: 6.1.0.Final
Environment: JBDS 8.0.0.CR1
JBDS-IS 8.0.0.Alpha2
Reporter: Tomáš Sedmík
Assignee: Mark Proctor
Priority: Minor
Attachments: Drools - Project Creation.png
A user can finish project creation wizard even if no Drools Runtime have been defined (see attachment). IMHO _Finish_ button should be enabled after a Drools Runtime has been defined.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month