[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski reassigned WFLY-5413:
------------------------------------
Assignee: Ondřej Chaloupka (was: Tomasz Adamski)
To make the change that you ask for we would need a change to PersistentResourceXMLDescription class in wildfly-core which currently does not marshall default values. Will make this change when possible.
I don't agree with "Bug" status of this Jira though - migration is working correctly, attributes have correct values which can be checked in CLI - this is only a presentation issue.
Can you switch it's type to enhancement please?
> On IIOP migration default properties are not persisted
> ------------------------------------------------------
>
> Key: WFLY-5413
> URL: https://issues.jboss.org/browse/WFLY-5413
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Ondřej Chaloupka
>
> If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML.
> It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly.
> The example of such properties which do not persist because of its default values are
> * initializers: security="none"
> * security: client-supports="ServerAuth" server-supports="MutualAuth"
> * security: client-requires="None" server-requires="None"
> * transport-config: detect-misordering="none"
> * as-context: auth-method="username_password" required="false"
> * sas-context caller-propagation="none"
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (WFLY-5536) Recovery manager is not able to recover MDB and shows warnings on each run.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5536?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5536:
-----------------------------------
There was an issue in the WildFly module definitions and the Artemis RA was using the default Artemis XAResourceWrapper instead of the one specific to WildFly.
Before, the trace was:
{noformat}
16:58:57,500 TRACE [org.apache.activemq.artemis.ra] (EJB default - 2) XAResource=org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl@3696bea
{noformat}
After the change (to import the services defined in the messaging-activemq extension) in https://github.com/wildfly/wildfly/compare/master...jmesnil:WFLY-5536_rec..., I now see:
{noformat}
17:17:26,576 TRACE [org.apache.activemq.artemis.ra] (EJB default - 4) XAResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper@7cd8de4e
{noformat}
This org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper class implants org.jboss.tm.XAResourceWrapper while its superclass is not implementing it.
However even with that change, the test is still failing.
For one transaction I can see that the Artemis RA start, ends and commits its xares:
{noformat}
17:16:03,598 TRACE [org.apache.activemq.artemis.ra] (EJB default - 5) start(< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80104:2ff694c:563397b2:1d, node_name=1, branch_uid=0:ffffc0a80104:2ff694c:563397b2:22, subordinatenodename=null, eis_name=java:/JmsXA NodeId:7a934c2e-7f21-11e5-83e2-a7afda8ee76d >, 0)
...
17:16:03,616 TRACE [org.apache.activemq.artemis.ra] (EJB default - 5) end(< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80104:2ff694c:563397b2:1d, node_name=1, branch_uid=0:ffffc0a80104:2ff694c:563397b2:22, subordinatenodename=null, eis_name=java:/JmsXA NodeId:7a934c2e-7f21-11e5-83e2-a7afda8ee76d >, 67108864)
...
17:16:03,618 TRACE [org.apache.activemq.artemis.ra] (EJB default - 5) commit(< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80104:2ff694c:563397b2:1d, node_name=1, branch_uid=0:ffffc0a80104:2ff694c:563397b2:22, subordinatenodename=null, eis_name=java:/JmsXA NodeId:7a934c2e-7f21-11e5-83e2-a7afda8ee76d >, true)
{noformat}
But for the transaction that's making the test fail (0:ffffc0a80104:2ff694c:563397b2:25), I see not such start/end/commit logs.
I only see:
{noformat}
17:16:36,390 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80104:2ff694c:563397b2:25, node_name=1, branch_uid=0:ffffc0a80104:2ff694c:563397b2:28, subordinatenodename=null, eis_name=java:/JmsXA NodeId:null >, heuristic: TwoPhaseOutcome.FINISH_OK, product: ActiveMQ Artemis/1.1.0.wildfly.007, jndiName: java:/JmsXA NodeId:null com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@eabf2ff >
{noformat}
> Recovery manager is not able to recover MDB and shows warnings on each run.
> ---------------------------------------------------------------------------
>
> Key: WFLY-5536
> URL: https://issues.jboss.org/browse/WFLY-5536
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Hayk Hovsepyan
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: MDB_JMS_XA.log
>
>
> Recovery manager is not able to recover MDB and shows warnings.
> This causes to see the same warning log in server each time recovery is run.
> This happens when server is crashed before transaction state is saved.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (WFCORE-889) Kerberos authentication for Management CLI should fallback when server principal is set incorrectly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-889?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-889:
------------------------------------
Fix Version/s: 2.0.1.Final (EAP 7)
3.0.0.Alpha1
(was: 2.0.0.Final)
> Kerberos authentication for Management CLI should fallback when server principal is set incorrectly
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-889
> URL: https://issues.jboss.org/browse/WFCORE-889
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 2.0.1.Final (EAP 7), 3.0.0.Alpha1
>
>
> In case when kerberos authentication is configured in security realm but principal attribute in keytab element is set incorrectly (e.g. remote/wrong_localhost(a)JBOSS.ORG, remote/localhost(a)WRONG_JBOSS.ORG or wrong_remote/localhost(a)JBOSS.ORG instead of remote/localhost(a)JBOSS.ORG) then authentication does not fallback into another authentication mechanism for user with valid kerberos ticket. In case when user does not have kerberos ticket then fallback is taken into account correctly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (WFCORE-1083) Login Module is messed up when one of the module-option is empty
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1083?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky commented on WFCORE-1083:
-------------------------------------------
It appears to be fixed in the current master which is WildFly 10.0.0.CR5 (wildfly-core 2.0.0.CR9). principalDNSPrefix will be stored as "undefined" in the XML.
> Login Module is messed up when one of the module-option is empty
> ----------------------------------------------------------------
>
> Key: WFCORE-1083
> URL: https://issues.jboss.org/browse/WFCORE-1083
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: CentOS Linux release 7.1.1503 (Core)
> /usr/java/jdk1.8.0_45/
> WildFly 8.2.0
> Reporter: J Prasanna Venkatesan
> Assignee: Alexey Loubyansky
> Priority: Critical
>
> When one of the module-option is given as empty the whole login-module is messed up. But in real time there will be cases where the module-option can be empty. For Eg. while configuring org.jboss.security.auth.spi.LdapLoginModule, the principalDNPrefix can be empty
> *+Command with principalDNPrefix empty+*
> /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapLoginModule33:add(code=org.jboss.security.auth.spi.LdapLoginModule, flag=sufficient, module-options=[ "java.naming.provider.url" => "ldap://ldaphost.jboss.org:1", "java.naming.security.authentication" => "simple", *"principalDNPrefix" => ""*, "principalDNSuffix" => ",ou=People,o=jboss.org", "allowEmptyPasswords" => "false", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "throwValidateError" => "true" ]){allow-resource-service-restart=true}
> +Output in standalone-full.xml+
> Wrong value is stored as principalDNPrefix
> <login-module name="org.jboss.security.auth.spi.LdapLoginModule33" code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient">
> <module-option name="java.naming.provider.url" value="ldap://ldaphost.jboss.org:1"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> *<module-option name="principalDNPrefix" value="principalDNSuffix"/>*
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="throwValidateError" value="true"/>
> </login-module>
> *+Command with principalDNPrefix with some value+*
> /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapLoginModule44:add(code=org.jboss.security.auth.spi.LdapLoginModule, flag=sufficient, module-options=[ "java.naming.provider.url" => "ldap://ldaphost.jboss.org:1", "java.naming.security.authentication" => "simple", *"principalDNPrefix" => "test"*, "principalDNSuffix" => ",ou=People,o=jboss.org", "allowEmptyPasswords" => "false", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "throwValidateError" => "true" ]){allow-resource-service-restart=true}
> +Output in standalone-full.xml+
> Values are stored correctly.
> <login-module name="org.jboss.security.auth.spi.LdapLoginModule44" code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient">
> <module-option name="java.naming.provider.url" value="ldap://ldaphost.jboss.org:1"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> *<module-option name="principalDNPrefix" value="test"/>*
> <module-option name="principalDNSuffix" value=",ou=People,o=jboss.org"/>
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="throwValidateError" value="true"/>
> </login-module>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader
by Satish Narayan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ]
Satish Narayan commented on DROOLS-618:
---------------------------------------
We ran into this as well. Is this truly a bug? Is there a safe work around?
> Thread deadlock on org.drools.util.CompositeClassLoader
> -------------------------------------------------------
>
> Key: DROOLS-618
> URL: https://issues.jboss.org/browse/DROOLS-618
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final
> Environment: drools expert
> Reporter: Shashank Agarwal
> Assignee: Mark Proctor
> Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt
>
>
> Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
> Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
> Name: http-54350-Processor15
> State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
> Name: http-54350-Processor18
> State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
> Name: http-54350-Processor20
> State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
> We do not have definite threads to re-produce the issue.
> But deadlocks are happening repeatedly on our production.
> Regarding out environment details:
> 1. We have windows box on which application runs.
> 2. The rules used are kept in .drl and .xls formats
> 3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
> 4. Setup a few session globals as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (WFLY-5614) org.hibernate:4.3 should not be alias for 5.0
by Scott Marlow (JIRA)
Scott Marlow created WFLY-5614:
----------------------------------
Summary: org.hibernate:4.3 should not be alias for 5.0
Key: WFLY-5614
URL: https://issues.jboss.org/browse/WFLY-5614
Project: WildFly
Issue Type: Feature Request
Components: JPA / Hibernate
Affects Versions: 10.0.0.CR4
Reporter: Scott Marlow
Assignee: Scott Marlow
modules/system/layers/base/org/hibernate/4.3/module.xml contains:
{quote}
<module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3" target-name="org.hibernate"/>
{quote}
org.hibernate:4.3 should be a real module (not alias) like org.hibernate:4.1 is.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months