January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-420) Incorrect resolution of global symbols in LHS rule constraint (Java dialect)

by Mike Rodriguez (JIRA)

Mike Rodriguez created DROOLS-420: ------------------------------------- Summary: Incorrect resolution of global symbols in LHS rule constraint (Java dialect) Key: DROOLS-420 URL: https://issues.jboss.org/browse/DROOLS-420 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mike Rodriguez Assignee: Mark Proctor Priority: Minor As described @ [http://drools.46999.n3.nabble.com/Incorrect-resolution-of-global-symbols-...]. I upgraded from 5.5.0.Final of Drools (rule engine) to 5.6.0.Final and I am now seeing errors with globals. We have rule constraints that access globals in a DRL; like this: {code}some.classpath.package2.MyType ( global_instance.invoke(this) == true ) {code} I have {code}some.classpath.package.SomeType global_instance;{code} declared at the top of the DRL, but it doesn't seem to be interpreting it as a global in the rule's restriction. So, putting this into context within, I have a DRL such as: package my.package.example; global some.classpath.package.SomeType global_instance; {code} rule "Example rule" when some.classpath.package2.MyType ( global_instance.invoke(this) == true ) then // do something end {code} I am getting an error from the package builder originating from the "Example rule" specifying something like: "can't find method MyType.global_instance()" Once, again this did work in 5.5.0.Final, but in 5.6.0.Final I am getting a failure trying to build the knowledge package. It looks to me like the {{global_instance}} symbol is not being recognized as a global in the DRL and is trying to be resolved as a method of the MyType class. So I guess it would be trying to do a "MyType.global_instance().invoke(this)" or something. The intent is that {{global_instance}} will be set for a session with an immutable function-type of class (invoke is an instance method though; not static). The rule restriction uses this function/predicate to determine if some complex criteria is true for `this` MyType instance. I would appreciate any insight into what the issue might be. I haven't been able to find any threads out there on a similar issue. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2841) Datasource mapped in jboss-web.xml not available to persistence unit

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2841?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-2841: ------------------------------- Forum Reference: http://lists.jboss.org/pipermail/wildfly-dev/2014-January/001541.html > Datasource mapped in jboss-web.xml not available to persistence unit > -------------------------------------------------------------------- > > Key: WFLY-2841 > URL: https://issues.jboss.org/browse/WFLY-2841 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.CR1 > Reporter: Martin Andersson > > I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application. > In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error: > 13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]} > A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/ -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2745) Typo in jboss-cli help message

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFLY-2745?page=com.atlassian.jira.plugin.... ] Alexey Loubyansky resolved WFLY-2745. ------------------------------------- Resolution: Done Fixed. Thanks! > Typo in jboss-cli help message > ------------------------------ > > Key: WFLY-2745 > URL: https://issues.jboss.org/browse/WFLY-2745 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 8.0.0.CR1 > Reporter: Arun Gupta > Assignee: Alexey Loubyansky > Priority: Trivial > Fix For: 8.0.0.Final > > > jboss-cli -h shows the following help message for --controller. > The default controller host is localhost and the port is 9999. > The port number should be 9990 instead of 9999. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2839) Remote Naming communication exception should be thrown on ConnectException

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.... ] Brad Maxwell edited comment on WFLY-2839 at 1/30/14 3:05 PM: ------------------------------------------------------------- Resolved in JBoss Remote Naming 2.0.0 Final & Wildfly fixed version will be via https://issues.jboss.org/browse/WFLY-2849 was (Author: bmaxwell): Resolved in JBoss Remote Naming 2.0.0 Final > Remote Naming communication exception should be thrown on ConnectException > -------------------------------------------------------------------------- > > Key: WFLY-2839 > URL: https://issues.jboss.org/browse/WFLY-2839 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException. This is related to WFLY-2198 -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2839) Remote Naming communication exception should be thrown on ConnectException

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.... ] Brad Maxwell commented on WFLY-2839: ------------------------------------ Resolved in JBoss Remote Naming 2.0.0 Final > Remote Naming communication exception should be thrown on ConnectException > -------------------------------------------------------------------------- > > Key: WFLY-2839 > URL: https://issues.jboss.org/browse/WFLY-2839 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException. This is related to WFLY-2198 -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2839) Remote Naming communication exception should be thrown on ConnectException

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.... ] Brad Maxwell resolved WFLY-2839. -------------------------------- Resolution: Done > Remote Naming communication exception should be thrown on ConnectException > -------------------------------------------------------------------------- > > Key: WFLY-2839 > URL: https://issues.jboss.org/browse/WFLY-2839 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException. This is related to WFLY-2198 -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2849) Upgrade jboss-remote-naming to 2.0.0 Final or later

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-2849: ---------------------------------- Summary: Upgrade jboss-remote-naming to 2.0.0 Final or later Key: WFLY-2849 URL: https://issues.jboss.org/browse/WFLY-2849 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Naming Affects Versions: 8.0.0.CR1 Reporter: Brad Maxwell Assignee: Eduardo Martins Upgrade jboss-remote-naming to 2.0.0 Final or later to resolve linked issues -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2849) Upgrade jboss-remote-naming to 2.0.0 Final or later

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-2849?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-2849: ------------------------------- Git Pull Request: (was: https://github.com/jbossas/jboss-remote-naming/commit/b3c34f54b350f220b48...) > Upgrade jboss-remote-naming to 2.0.0 Final or later > --------------------------------------------------- > > Key: WFLY-2849 > URL: https://issues.jboss.org/browse/WFLY-2849 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Eduardo Martins > > Upgrade jboss-remote-naming to 2.0.0 Final or later to resolve linked issues -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1786) TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on JGRP-1786 at 1/30/14 2:58 PM: -------------------------------------------------------------------- Note 1: I am logging bugs which are repeatable and occur across multiple platforms only, to minimize the number of issues logged. Note 2: There is a limit to the amount of root cause analysis I can do on these bugs. I'll try my best but ... was (Author: rachmato): One note: I am logging bugs which are repeatable and occur across multiple platforms only, to minimize the number of issues logged. > TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler > ----------------------------------------------------------------------- > > Key: JGRP-1786 > URL: https://issues.jboss.org/browse/JGRP-1786 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL 5 x86_64 > Windows x86_64 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > > The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute > Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted. > The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel. > -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1786) TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz updated JGRP-1786: -------------------------------------- Description: The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted. The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel. was: The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted. > TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler > ----------------------------------------------------------------------- > > Key: JGRP-1786 > URL: https://issues.jboss.org/browse/JGRP-1786 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL 5 x86_64 > Windows x86_64 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > > The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute > Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted. > The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel. > -- 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

12 years, 3 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 January 2014