[JBoss JIRA] (WFLY-2828) "WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2828?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-2828:
--------------------------------
Component/s: EJB
(was: Transactions)
> "WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2828
> URL: https://issues.jboss.org/browse/WFLY-2828
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Tom Jenkinson
>
> About 1/4 times.
> {noformat}
> 13:26:27,786 INFO [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 7076ms
> 13:26:27,787 INFO [org.jboss.as] (MSC service thread 1-5) JBAS015899: WildFly 8.0.0.Final-SNAPSHOT "WildFly" starting
> 13:26:27,861 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:26:27,874 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 35) JBAS010280: Activating Infinispan subsystem.
> 13:26:27,875 INFO [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final)
> 13:26:27,877 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 39) JBAS010260: Activating JGroups subsystem.
> 13:26:27,894 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 45) JBAS011800: Activating Naming Subsystem
> 13:26:27,895 INFO [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> 13:26:27,897 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> 13:26:27,897 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,897 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,900 INFO [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.20.Final
> 13:26:27,900 INFO [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
> 13:26:27,901 WARN [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011706: Metric of type 'mem' is no longer supported and will be ignored.
> 13:26:27,901 INFO [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 13:26:27,901 INFO [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011704: Mod_cluster uses default load balancer provider
> 13:26:27,901 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 13:26:27,904 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) JBAS010417: Started Driver service with driver-name = h2
> 13:26:27,906 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017527: Creating file handler for path /home/rhusar/as/build/target/wildfly-8.0.0.Final-SNAPSHOT/welcome-content
> 13:26:27,909 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017525: Started server default-server.
> 13:26:27,909 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017531: Host default-host starting
> 13:26:27,915 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {noformat}
--
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
[JBoss JIRA] (WFLY-2828) "WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2828?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-2828:
--------------------------------
Assignee: David Lloyd (was: Tom Jenkinson)
> "WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2828
> URL: https://issues.jboss.org/browse/WFLY-2828
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: David Lloyd
>
> About 1/4 times.
> {noformat}
> 13:26:27,786 INFO [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 7076ms
> 13:26:27,787 INFO [org.jboss.as] (MSC service thread 1-5) JBAS015899: WildFly 8.0.0.Final-SNAPSHOT "WildFly" starting
> 13:26:27,861 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:26:27,874 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 35) JBAS010280: Activating Infinispan subsystem.
> 13:26:27,875 INFO [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final)
> 13:26:27,877 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 39) JBAS010260: Activating JGroups subsystem.
> 13:26:27,894 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 45) JBAS011800: Activating Naming Subsystem
> 13:26:27,895 INFO [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> 13:26:27,897 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> 13:26:27,897 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,897 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,900 INFO [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.20.Final
> 13:26:27,900 INFO [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
> 13:26:27,901 WARN [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011706: Metric of type 'mem' is no longer supported and will be ignored.
> 13:26:27,901 INFO [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 13:26:27,901 INFO [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011704: Mod_cluster uses default load balancer provider
> 13:26:27,901 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 13:26:27,904 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) JBAS010417: Started Driver service with driver-name = h2
> 13:26:27,906 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017527: Creating file handler for path /home/rhusar/as/build/target/wildfly-8.0.0.Final-SNAPSHOT/welcome-content
> 13:26:27,909 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017525: Started server default-server.
> 13:26:27,909 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017531: Host default-host starting
> 13:26:27,915 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {noformat}
--
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
[JBoss JIRA] (WFLY-2828) "WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2828?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-2828:
-------------------------------------
Looks like it is coming out of the EJB code, so reassigning to EJB default component owner
> "WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2828
> URL: https://issues.jboss.org/browse/WFLY-2828
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: David Lloyd
>
> About 1/4 times.
> {noformat}
> 13:26:27,786 INFO [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 7076ms
> 13:26:27,787 INFO [org.jboss.as] (MSC service thread 1-5) JBAS015899: WildFly 8.0.0.Final-SNAPSHOT "WildFly" starting
> 13:26:27,861 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:26:27,874 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 35) JBAS010280: Activating Infinispan subsystem.
> 13:26:27,875 INFO [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final)
> 13:26:27,877 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 39) JBAS010260: Activating JGroups subsystem.
> 13:26:27,894 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 45) JBAS011800: Activating Naming Subsystem
> 13:26:27,895 INFO [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> 13:26:27,897 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> 13:26:27,897 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,897 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,900 INFO [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.20.Final
> 13:26:27,900 INFO [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
> 13:26:27,901 WARN [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011706: Metric of type 'mem' is no longer supported and will be ignored.
> 13:26:27,901 INFO [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 13:26:27,901 INFO [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011704: Mod_cluster uses default load balancer provider
> 13:26:27,901 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 13:26:27,904 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) JBAS010417: Started Driver service with driver-name = h2
> 13:26:27,906 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017527: Creating file handler for path /home/rhusar/as/build/target/wildfly-8.0.0.Final-SNAPSHOT/welcome-content
> 13:26:27,909 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017525: Started server default-server.
> 13:26:27,909 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017531: Host default-host starting
> 13:26:27,915 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {noformat}
--
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
[JBoss JIRA] (WFLY-1597) Re-Review TLS/SSL where http-upgrade is in use.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1597?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-1597.
------------------------------------
Resolution: Done
> Re-Review TLS/SSL where http-upgrade is in use.
> -----------------------------------------------
>
> Key: WFLY-1597
> URL: https://issues.jboss.org/browse/WFLY-1597
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Remoting, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Need to double check the behaviour here, the wrapping of Remoting so far it leaving the Remoting specific messages as-is - need to verify we are not double encrypting the connection and also the Client Cert based authentication requirements on that connection.
--
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
[JBoss JIRA] (WFLY-2322) Update add-user to REJECT bad passwords
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2322?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2322:
----------------------------------------
Actually it is only a one line change ;-) Overall the reasoning is ship by default mandating the password restrictions and an administrator can make the one line change and relax the checking again.
In the past this is just one of those areas we have been called out on that we don't enforce password strength rules.
> Update add-user to REJECT bad passwords
> ---------------------------------------
>
> Key: WFLY-2322
> URL: https://issues.jboss.org/browse/WFLY-2322
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Before we release .Final add-user.sh should be switched back to rejecting bad passwords rather than just warning.
--
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
[JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using timezone when calcualting next timeout
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.... ]
Brad Maxwell edited comment on WFLY-2840 at 1/30/14 12:39 AM:
--------------------------------------------------------------
The issue appears to be in
org.jboss.as.ejb3.timerservice.task.CalendarTimerTask
It looks like calculateNextTimeout, Calendar cal = new GregorianCalendar(), should take in the timezone specified in the ScheduleExpression, such as :
TimeZone tz = TimeZone.getTimeZone(((CalendarTimer) timer).getCalendarTimeout().getScheduleExpression().getTimezone());
Calendar cal = new GregorianCalendar(tz);
Or actually, CalendarTimerTask is calling CalendarBasedTimeout.getNextTimeout which takes in the calendar created from CalendarTimerTask, and it has access to the scheduleExpression, so that is probably the better place to change it.
org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.getNextTimeout
nextCal.setTimeZone(TimeZone.getTimeZone(scheduleExpression.getTimezone()));
Currently:
21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
With Change:
21:51:00,025 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 21:52:00 CST 2014
21:52:00,002 INFO [stdout] (EJB default - 2) ScheduleTest: nextTimeout:Wed Jan 29 21:53:00 CST 2014
...
was (Author: bmaxwell):
The issue appears to be in
org.jboss.as.ejb3.timerservice.task.CalendarTimerTask
It looks like calculateNextTimeout, Calendar cal = new GregorianCalendar(), should take in the timezone specified in the ScheduleExpression, such as :
TimeZone tz = TimeZone.getTimeZone(((CalendarTimer) timer).getCalendarTimeout().getScheduleExpression().getTimezone());
Calendar cal = new GregorianCalendar(tz);
Currently:
21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
With Change:
21:51:00,025 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 21:52:00 CST 2014
21:52:00,002 INFO [stdout] (EJB default - 2) ScheduleTest: nextTimeout:Wed Jan 29 21:53:00 CST 2014
...
> @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
12 years, 3 months
[JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using timezone when calcualting next timeout
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.... ]
Brad Maxwell updated WFLY-2840:
-------------------------------
Description:
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}
was:
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 = "*")
21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
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());
}
}
> @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
12 years, 3 months
[JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using timezone when calcualting next timeout
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.... ]
Brad Maxwell updated WFLY-2840:
-------------------------------
Description:
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 = "*")
21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
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());
}
}
was:
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.
@Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
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());
}
}
> @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 = "*")
> 21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
> 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());
> }
> }
--
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
[JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using timezone when calcualting next timeout
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.... ]
Brad Maxwell commented on WFLY-2840:
------------------------------------
The issue appears to be in
org.jboss.as.ejb3.timerservice.task.CalendarTimerTask
It looks like calculateNextTimeout, Calendar cal = new GregorianCalendar(), should take in the timezone specified in the ScheduleExpression, such as :
TimeZone tz = TimeZone.getTimeZone(((CalendarTimer) timer).getCalendarTimeout().getScheduleExpression().getTimezone());
Calendar cal = new GregorianCalendar(tz);
Currently:
21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
With Change:
21:51:00,025 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 21:52:00 CST 2014
21:52:00,002 INFO [stdout] (EJB default - 2) ScheduleTest: nextTimeout:Wed Jan 29 21:53:00 CST 2014
...
> @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.
> @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
> 21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
> 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());
> }
> }
--
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
[JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using timezone when calcualting next timeout
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-2840:
----------------------------------
Summary: @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.
@Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
21:53:00,006 INFO [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
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());
}
}
--
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