February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5569) Module dependencies don't work correctly when JAAS login is used in deployments

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5569?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-5569. ------------------------------------ Fix Version/s: 10.1.0.Final Resolution: Won't Fix This is going to be superseded by Elytron at some point anyway, however as from my initial assessment this is far from trivial to address so the application is required to take responsibility for class loading if it is using the LoginContext directly. > Module dependencies don't work correctly when JAAS login is used in deployments > ------------------------------------------------------------------------------- > > Key: WFLY-5569 > URL: https://issues.jboss.org/browse/WFLY-5569 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Fix For: 10.1.0.Final > > > When user wants to use direct JAAS login call from a deployment (e.g. servlet), (s)he will experience problems when LoginModule is placed in custom AS module. > Login modules works correctly if they come from PicketBox, but new modules doesn't work. > This issue is based on [this StackOverflow question|http://stackoverflow.com/questions/33203277/wildfly-and-jaas-log...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5569) Module dependencies don't work correctly when JAAS login is used in deployments

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5569?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-5569: -------------------------------------- Assignee: Darran Lofthouse > Module dependencies don't work correctly when JAAS login is used in deployments > ------------------------------------------------------------------------------- > > Key: WFLY-5569 > URL: https://issues.jboss.org/browse/WFLY-5569 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > > When user wants to use direct JAAS login call from a deployment (e.g. servlet), (s)he will experience problems when LoginModule is placed in custom AS module. > Login modules works correctly if they come from PicketBox, but new modules doesn't work. > This issue is based on [this StackOverflow question|http://stackoverflow.com/questions/33203277/wildfly-and-jaas-log...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6125) [Migration operation] No migration warning for remoting-interceptors

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6125?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-3210 to WFLY-6125: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6125 (was: JBEAP-3210) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) (was: Migration) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.ER4) > [Migration operation] No migration warning for remoting-interceptors > -------------------------------------------------------------------- > > Key: WFLY-6125 > URL: https://issues.jboss.org/browse/WFLY-6125 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > There is missing warning if following configuration is migrated to messaging-activemq subsystem: > {code} > <remoting-interceptors> > <class-name> > org.jboss.qa.hornetq.apps.interceptors.LargeMessagePacketInterceptorImpl > </class-name> > <class-name> > org.jboss.qa.hornetq.apps.interceptors.LargeMessagePacketInterceptorImpl > </class-name> > </remoting-interceptors> > {code} > There should be warning like: > {{WFLYMSG0082: Classes providing the remoting-incoming-interceptors are discarded during the migration. To use them in the new messaging-activemq subsystem, you will have to extend the Artemis-based Interceptor.}} > as for migration of remoting-incoming-interceptors and remoting-outgoing-interceptors. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6124) Infinispan subsystem XSD disagrees with LockingResourceDefinition on default isolation level

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFLY-6124?page=com.atlassian.jira.plugin.... ] Ladislav Thon updated WFLY-6124: -------------------------------- Affects Version/s: 10.0.0.Final > Infinispan subsystem XSD disagrees with LockingResourceDefinition on default isolation level > -------------------------------------------------------------------------------------------- > > Key: WFLY-6124 > URL: https://issues.jboss.org/browse/WFLY-6124 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Ladislav Thon > Assignee: Paul Ferraro > > The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says that the default isolation level is {{REPEATABLE_READ}}: > {code} > <xs:complexType name="locking"> > <xs:attribute name="isolation" type="tns:isolation" default="REPEATABLE_READ"> > <xs:annotation> > <xs:documentation>Sets the cache locking isolation level.</xs:documentation> > </xs:annotation> > </xs:attribute> > ... > {code} > However, the {{LockingResourceDefinition}} class, which is the ultimate source of truth, disagrees: > {code} > enum Attribute implements org.jboss.as.clustering.controller.Attribute { > ... > ISOLATION("isolation", ModelType.STRING, new ModelNode(IsolationLevel.READ_COMMITTED.name()), new EnumValidatorBuilder<>(IsolationLevel.class)), > ... > {code} > I'm not sure myself which one should be the default, but this difference is surely a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6124) Infinispan subsystem XSD disagrees with LockingResourceDefinition on default isolation level

by Ladislav Thon (JIRA)

Ladislav Thon created WFLY-6124: ----------------------------------- Summary: Infinispan subsystem XSD disagrees with LockingResourceDefinition on default isolation level Key: WFLY-6124 URL: https://issues.jboss.org/browse/WFLY-6124 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Ladislav Thon Assignee: Paul Ferraro The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says that the default isolation level is {{REPEATABLE_READ}}: {code} <xs:complexType name="locking"> <xs:attribute name="isolation" type="tns:isolation" default="REPEATABLE_READ"> <xs:annotation> <xs:documentation>Sets the cache locking isolation level.</xs:documentation> </xs:annotation> </xs:attribute> ... {code} However, the {{LockingResourceDefinition}} class, which is the ultimate source of truth, disagrees: {code} enum Attribute implements org.jboss.as.clustering.controller.Attribute { ... ISOLATION("isolation", ModelType.STRING, new ModelNode(IsolationLevel.READ_COMMITTED.name()), new EnumValidatorBuilder<>(IsolationLevel.class)), ... {code} I'm not sure myself which one should be the default, but this difference is surely a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1017) NPE deleting an expired event in equality mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1017?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1017: ------------------------------------------------- Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1295433|https://bugzilla.redhat.com/show_bug.cgi?id=1295433] from MODIFIED to ON_QA > NPE deleting an expired event in equality mode > ---------------------------------------------- > > Key: DROOLS-1017 > URL: https://issues.jboss.org/browse/DROOLS-1017 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.0.Beta1 > > > Trying to delete an already expired event in equality mode causes the following NPE in the TMS: > {code} > java.lang.NullPointerException > at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:506) > at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:442) > at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1120) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274) > at org.drools.compiler.integrationtests.CepEspTest.testDeleteExpiredEventWithTimestampAndEqualityKey(CepEspTest.java:5682) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1007) ArrayIndexOutOfBoundsException attempting to remove a rule containing a OR

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1007?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1007: ------------------------------------------------- Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1291749|https://bugzilla.redhat.com/show_bug.cgi?id=1291749] from MODIFIED to ON_QA > ArrayIndexOutOfBoundsException attempting to remove a rule containing a OR > -------------------------------------------------------------------------- > > Key: DROOLS-1007 > URL: https://issues.jboss.org/browse/DROOLS-1007 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.0.Beta1 > > > At the moment the association between a node and a rule is kept by a Map inside the node having the rule as key. This implementation is not taking count of the fact that the same node could be associated multiple times to the same rule that it is indeed what happens when a rule contains a OR. > During the removal of such a rule the nodes of the rule are removed from the Rete starting from the RuleTerminalNodes (in this case the rule has more than one RTNs because of the OR). This means that when the first RTN is removed the Join and LIA nodes that are sources for that RTN at any level got completely disassociated from the rule when it is too early. That in the end causes the following exception when the engine tries to remove also the second RTN of that rule > {code} > java.lang.ArrayIndexOutOfBoundsException: 1 > at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:171) > at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:173) > at org.drools.core.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:163) > at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1635) > at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1626) > at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1610) > at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1581) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1009) lambda expressions cannot be parsed by ecj/janino

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1009?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1009: ------------------------------------------------- Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1199965|https://bugzilla.redhat.com/show_bug.cgi?id=1199965] from MODIFIED to ON_QA > lambda expressions cannot be parsed by ecj/janino > ------------------------------------------------- > > Key: DROOLS-1009 > URL: https://issues.jboss.org/browse/DROOLS-1009 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.3.0.Final > Reporter: Malte Brunnlieb > Assignee: Mario Fusco > Fix For: 6.4.0.Beta1 > > > Using Java8 lambda expression in the decision template like > bean1.call(() -> $param); > you will run into compiler issues with ejc as well as the currently supported version of JANINO (2.5.16). I tried to manually upgrade the JANINO compiler version, but got stuck in compatibility issues as the Scanner seems to have been changed regarding exception handling. > Can you suggest to fix the incompatibility with JANINO > 2.5.16 such that lambda expressions can be parsed by the newest parsers? Would be nice :) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6123) Infinispan subsystem XSD doesn't document all possible values of <transaction mode="...">

by Ladislav Thon (JIRA)

Ladislav Thon created WFLY-6123: ----------------------------------- Summary: Infinispan subsystem XSD doesn't document all possible values of <transaction mode="..."> Key: WFLY-6123 URL: https://issues.jboss.org/browse/WFLY-6123 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Ladislav Thon Assignee: Paul Ferraro The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says the following about {{<transaction mode="...">}}: bq. Sets the cache transaction mode to one of NONE, NON_XA, NON_DURABLE_XA, FULL_XA. However, the enum {{org.jboss.as.clustering.infinispan.subsystem.TransactionMode}} has the following values: - {{NONE}} - {{BATCH}} - {{NON_XA}} - {{NON_DURABLE_XA}} - {{FULL_XA}} I.e., the {{BATCH}} value is missing from the documentation. Interestingly, {{BATCH}} is also used in the default config for all the {{web}} and {{ejb}} caches. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6123) Infinispan subsystem XSD doesn't document all possible values of <transaction mode="...">

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFLY-6123?page=com.atlassian.jira.plugin.... ] Ladislav Thon updated WFLY-6123: -------------------------------- Affects Version/s: 10.0.0.Final > Infinispan subsystem XSD doesn't document all possible values of <transaction mode="..."> > ----------------------------------------------------------------------------------------- > > Key: WFLY-6123 > URL: https://issues.jboss.org/browse/WFLY-6123 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Ladislav Thon > Assignee: Paul Ferraro > > The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says the following about {{<transaction mode="...">}}: > bq. Sets the cache transaction mode to one of NONE, NON_XA, NON_DURABLE_XA, FULL_XA. > However, the enum {{org.jboss.as.clustering.infinispan.subsystem.TransactionMode}} has the following values: > - {{NONE}} > - {{BATCH}} > - {{NON_XA}} > - {{NON_DURABLE_XA}} > - {{FULL_XA}} > I.e., the {{BATCH}} value is missing from the documentation. Interestingly, {{BATCH}} is also used in the default config for all the {{web}} and {{ejb}} caches. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016