January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using timezone when calcualting next timeout

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2840: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059911, https://bugzilla.redhat.com/show_bug.cgi?id=1059914 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1059911) > @Schedule EJB Timer not using timezone when calcualting next timeout > -------------------------------------------------------------------- > > Key: WFLY-2840 > URL: https://issues.jboss.org/browse/WFLY-2840 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: David Lloyd > > With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour. > The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern. If it did, then the timer should continue to fire every minute. > {code} > @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*") > {code} > 21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014 > {code} > import javax.ejb.Schedule; > import javax.ejb.Singleton; > import javax.ejb.Startup; > @Startup > @Singleton > public class ScheduleTest { > @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*") > public void helloWorld(Timer time) { > System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo()); > } > } > {code} -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using timezone when calcualting next timeout

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2840: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059911 > @Schedule EJB Timer not using timezone when calcualting next timeout > -------------------------------------------------------------------- > > Key: WFLY-2840 > URL: https://issues.jboss.org/browse/WFLY-2840 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Brad Maxwell > Assignee: David Lloyd > > With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour. > The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern. If it did, then the timer should continue to fire every minute. > {code} > @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*") > {code} > 21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014 > {code} > import javax.ejb.Schedule; > import javax.ejb.Singleton; > import javax.ejb.Startup; > @Startup > @Singleton > public class ScheduleTest { > @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*") > public void helloWorld(Timer time) { > System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo()); > } > } > {code} -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2831) Method Utils.getSecondaryTestAddress(ManagementClient, boolean) doesn't strip square brackets from host IPv6 address

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2831?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2831: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1059260|https://bugzilla.redhat.com/show_bug.cgi?id=1059260] from POST to MODIFIED > Method Utils.getSecondaryTestAddress(ManagementClient, boolean) doesn't strip square brackets from host IPv6 address > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-2831 > URL: https://issues.jboss.org/browse/WFLY-2831 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > The striping of square brackets around IPv6 addresses doesn't work in > org.jboss.as.test.integration.security.common.Utils.getSecondaryTestAddress(ManagementClient, boolean), it causes failures of AdvancedLdapLoginModuleTestCase. -- 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

10 years, 3 months

1
0
0 / 0

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

by Mike Rodriguez (JIRA)

[ https://issues.jboss.org/browse/DROOLS-420?page=com.atlassian.jira.plugin... ] Mike Rodriguez commented on DROOLS-420: --------------------------------------- This was discovered when upgrading to 5.6.0.Final from 5.5.0.Final. I was not seeing a 5.6.0.Final affects version when making this Jira. According to [this|http://drools.46999.n3.nabble.com/Incorrect-resolution-of-global-sym...], it affects Drools 6.x too. > 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

10 years, 3 months

1
0
0 / 0

[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

10 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

10 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

10 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

10 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

10 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

10 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2014