February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4303) Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-4303: -------------------------------------- Summary: Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true Key: WFLY-4303 URL: https://issues.jboss.org/browse/WFLY-4303 Project: WildFly Issue Type: Feature Request Reporter: Wolf-Dieter Fink Assignee: Jason Greene Applications need to have a jboss-ejb-client.xml configuration to use connections to other WildFly servers. The remote-outbound-connection allow expressions, i.e. for user-name. But if a cluster come into play the related <cluster> element inside the jboss-ejb-client.xml must have the same username and this can be only hardcoded. So the jboss-ejb-client.xml parsing should allow expressions for outbound-connection-ref, username, security-realm etc. See https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-ma... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4295) warn about _ds.xml deplyments are deprecated

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4295?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4295: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1187026|https://bugzilla.redhat.com/show_bug.cgi?id=1187026] from POST to MODIFIED > warn about _ds.xml deplyments are deprecated > -------------------------------------------- > > Key: WFLY-4295 > URL: https://issues.jboss.org/browse/WFLY-4295 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > _ds.xml deployement will no more supported in next vesions of WF. log a warning during deployment to warn users about that. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4302) Missing dependency on org.wildfly.clustering.infinispan.spi in org.jboss.as.security module

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-4302: ---------------------------------- Summary: Missing dependency on org.wildfly.clustering.infinispan.spi in org.jboss.as.security module Key: WFLY-4302 URL: https://issues.jboss.org/browse/WFLY-4302 Project: WildFly Issue Type: Bug Components: Clustering, Security Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4299) transaction subsystem node-identifier can not resolve expression

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4299?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4299: ----------------------------------- i think this is related to WFCORE-499 > transaction subsystem node-identifier can not resolve expression > ---------------------------------------------------------------- > > Key: WFLY-4299 > URL: https://issues.jboss.org/browse/WFLY-4299 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Brian Stansberry > Priority: Critical > Labels: configuration, configuration_management, domain > > If the transaction subsystem should use an expression as node-identifier this will not work in domain mode: > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 36) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: "WFLYCTL0211: Cannot resolve expression '${txNodeIdentifier}'" > This was possible in former builds with the same configuration. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-694) accumulate with sliding window and other LHS condition

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-694?page=com.atlassian.jira.plugin... ] Matteo Mortari commented on DROOLS-694: --------------------------------------- Ciao Mario, thank you very much for the feedback; I'm glad to see this reproducer, although not fully "reduced", was helpful to locate a bug. ps: thanks also for the hint but in this case within the application I discovered this issue, it's very common to need (or prefer) no-loop, so I guess I just "generalized" the case where I spotted this rule failing when using phreak. > accumulate with sliding window and other LHS condition > ------------------------------------------------------ > > Key: DROOLS-694 > URL: https://issues.jboss.org/browse/DROOLS-694 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR4 > Environment: fail with PHREAK, work correctly as expected with RETEOO > Reporter: Matteo Mortari > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > Attachments: 20150121.accumulate-window-counter.zip > > > With reference to attached reproducer. > Assuming the following KB, where to goal is to keep a {{Counter}} fact for the amount of {{Measurement}} events received in the last hour. > {code:java} > declare Measurement > @role(event) > end > rule "Init Counter last 1h" > agenda-group "USERSPACE" > salience 1 > no-loop > when > not Counter( name == "Counter last 1h" ) > then > Counter c = new Counter("Counter last 1h", 0); > insert(c); > System.out.println("RHS Init Counter last 1h " + c); > end > rule "Update Counter last 1h" > agenda-group "USERSPACE" > no-loop > when > accumulate( $token : Measurement() over window:time( 1h ) ; > $val : count($token) > ) > $cv1 : Counter( name == "Counter last 1h", value != $val.doubleValue() ) > then > int count = $val.intValue(); > $cv1.setValue(count); > update($cv1); > System.out.println("RHS Update Counter last 1h : "+$cv1); > end > {code} > The following Unit test shall have the effect in the end to obtain value 2.0 in the {{Counter}} object, as I've inserted 2 {{MEasurement}} within the last hour and within two minutes > {code:java} > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "220")); > fire(session); > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "221")); > fire(session); > LOG.info("Final checks"); > Counter counter = (Counter) session.getObjects(counterFilter).iterator().next(); // I'm taking a shortcut as for this reproducer I know there is only 1 Counter in WM > assertEquals("I've inserted 2 Measurement within the hour ", 2, counter.getValue(), 0); > {code} > However this works only with ReteOO and the test FAILS with Phreak. > Can you kindly advise, please? > Thank you > MM -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-694) accumulate with sliding window and other LHS condition

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-694?page=com.atlassian.jira.plugin... ] Matteo Mortari edited comment on DROOLS-694 at 2/2/15 8:32 AM: --------------------------------------------------------------- Ciao Mario, thank you very much for the feedback; I'm glad to see this reproducer, although not fully "reduced", was helpful to locate a bug. ps: thanks also for the hint but in this case within the application I discovered this issue, it's very common to need (or prefer) no-loop, so I just "generalized" the case where I spotted this rule failing when using phreak. was (Author: tari_manga): Ciao Mario, thank you very much for the feedback; I'm glad to see this reproducer, although not fully "reduced", was helpful to locate a bug. ps: thanks also for the hint but in this case within the application I discovered this issue, it's very common to need (or prefer) no-loop, so I guess I just "generalized" the case where I spotted this rule failing when using phreak. > accumulate with sliding window and other LHS condition > ------------------------------------------------------ > > Key: DROOLS-694 > URL: https://issues.jboss.org/browse/DROOLS-694 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR4 > Environment: fail with PHREAK, work correctly as expected with RETEOO > Reporter: Matteo Mortari > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > Attachments: 20150121.accumulate-window-counter.zip > > > With reference to attached reproducer. > Assuming the following KB, where to goal is to keep a {{Counter}} fact for the amount of {{Measurement}} events received in the last hour. > {code:java} > declare Measurement > @role(event) > end > rule "Init Counter last 1h" > agenda-group "USERSPACE" > salience 1 > no-loop > when > not Counter( name == "Counter last 1h" ) > then > Counter c = new Counter("Counter last 1h", 0); > insert(c); > System.out.println("RHS Init Counter last 1h " + c); > end > rule "Update Counter last 1h" > agenda-group "USERSPACE" > no-loop > when > accumulate( $token : Measurement() over window:time( 1h ) ; > $val : count($token) > ) > $cv1 : Counter( name == "Counter last 1h", value != $val.doubleValue() ) > then > int count = $val.intValue(); > $cv1.setValue(count); > update($cv1); > System.out.println("RHS Update Counter last 1h : "+$cv1); > end > {code} > The following Unit test shall have the effect in the end to obtain value 2.0 in the {{Counter}} object, as I've inserted 2 {{MEasurement}} within the last hour and within two minutes > {code:java} > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "220")); > fire(session); > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "221")); > fire(session); > LOG.info("Final checks"); > Counter counter = (Counter) session.getObjects(counterFilter).iterator().next(); // I'm taking a shortcut as for this reproducer I know there is only 1 Counter in WM > assertEquals("I've inserted 2 Measurement within the hour ", 2, counter.getValue(), 0); > {code} > However this works only with ReteOO and the test FAILS with Phreak. > Can you kindly advise, please? > Thank you > MM -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-73) NPE in RootResourceIterator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-73?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-73: --------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1185118|https://bugzilla.redhat.com/show_bug.cgi?id=1185118] from POST to MODIFIED > NPE in RootResourceIterator > --------------------------- > > Key: WFLY-73 > URL: https://issues.jboss.org/browse/WFLY-73 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JMX > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.Alpha1 > > > Intermittent testsuite failures, e.g. > http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-param-pull/684... > Log shows this repeatedly: > [0m[33m18:38:11,612 WARN [org.jboss.remotingjmx.protocol.v2.ServerCommon] (pool-2-thread-12) Unexpected internal error: java.lang.NullPointerException > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:49) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:55) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:55) > at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:39) > at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:103) > at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:116) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:220) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:618) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13] > RootResourceIterator.doIterate is reading the resource twice: > {code} > for (ResourceEntry entry : current.getChildren(type)) { > final PathElement pathElement = entry.getPathElement(); > final Resource child = current.getChild(pathElement); // why this call since "entry" and "child" should be the same object > final PathAddress childAddress = address.append(pathElement); > doIterate(child, childAddress); > } > {code} > The problem is "child" is null, which is possible with a dynamic resource. So, either "entry" should be used, or, if there is some reason for the 2nd read, a check for null is needed before the recursive doIterate call. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-523) wildfly-init-redhat.sh should touch /var/lock/subsys/wildfly for properly shutdown

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-523?page=com.atlassian.jira.plugin... ] Kabir Khan closed WFCORE-523. ----------------------------- Fix Version/s: 1.0.0.Alpha17 Resolution: Done > wildfly-init-redhat.sh should touch /var/lock/subsys/wildfly for properly shutdown > ---------------------------------------------------------------------------------- > > Key: WFCORE-523 > URL: https://issues.jboss.org/browse/WFCORE-523 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Affects Versions: 1.0.0.Alpha16 > Environment: CentOS 6.6 > Reporter: Kohei Nozaki > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha17 > > > When I shutdown CentOS, it doesn't wait for complete shutdown of WildFly. I see that server.log doesn't end with `JBAS015950: WildFly 8.2.0.Final "Tweek" stopped in 437ms` at shutdown of CentOS. also there's no message which indicates that processing of WildFly shutdown (e.g. Stopping wildfly...). it seems like that shutdown script was not invoked and CentOS killed the process of WildFly. > It's not good for embedded database that requires shutdown properly. I have a embedded Derby within WildFly and it needs properly shutdown for every time to avoid data corruption. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4296) remove _ds.xml deployment support

by arjan tijms (JIRA)

[ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.... ] arjan tijms commented on WFLY-4296: ----------------------------------- {quote}Why is this to be removed?{quote} I can only guess, but perhaps because approximately the same thing can now be done using the Java EE standard {{application.xml}}, {{ejb-jar.xml}} and {{web.xml}} files? > remove _ds.xml deployment support > --------------------------------- > > Key: WFLY-4296 > URL: https://issues.jboss.org/browse/WFLY-4296 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Fix For: No Release > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-141) Add a Credential to Name Resolver SPI

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-141: ------------------------------------ Summary: Add a Credential to Name Resolver SPI Key: ELY-141 URL: https://issues.jboss.org/browse/ELY-141 Project: WildFly Elytron Issue Type: Feature Request Components: API / SPI Reporter: Darran Lofthouse Fix For: 1.0.0.Alpha1 We are predominantly considering this in the context of the validation side of the API. However should still not exclude the possibility that after obtaining a RealmIdentity the validation may still be performed in the mechanism. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 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 2015