February 2014 - jboss-jira - Jboss List Archives

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2840: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1059914|https://bugzilla.redhat.com/show_bug.cgi?id=1059914] from MODIFIED to ON_QA > @Schedule EJB Timer not using timezone when calculating 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: Brad Maxwell > Fix For: 8.0.0.Final > > > 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2198) Remote Naming throws the same exception for different causes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2198: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1053426|https://bugzilla.redhat.com/show_bug.cgi?id=1053426] from MODIFIED to ON_QA > Remote Naming throws the same exception for different causes > ------------------------------------------------------------ > > Key: WFLY-2198 > URL: https://issues.jboss.org/browse/WFLY-2198 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported. > We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. > If all the the servers specified are not not running: > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) > If one of the servers is running, but the client's username/password are incorrect > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-795) AdvancedLdap login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-795?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-795: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1065513|https://bugzilla.redhat.com/show_bug.cgi?id=1065513] from MODIFIED to ON_QA > AdvancedLdap login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-795 > URL: https://issues.jboss.org/browse/SECURITY-795 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Derek Horton > Fix For: Negotiation_2_2_7 > > Attachments: SECURITY-795.patch > > > AdvancedLdap login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-797) Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-797: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1067612|https://bugzilla.redhat.com/show_bug.cgi?id=1067612] from MODIFIED to ON_QA > Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-797 > URL: https://issues.jboss.org/browse/SECURITY-797 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-797.patch > > > If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail. Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles. > It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set. This causes an exception which in turn causes the authentication attempt to fail. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-796) LdapExtended login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-796?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-796: -------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1067599|https://bugzilla.redhat.com/show_bug.cgi?id=1067599] from MODIFIED to ON_QA > LdapExtended login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-796 > URL: https://issues.jboss.org/browse/SECURITY-796 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-796.patch > > > LdapExtended login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3040) Missing modules

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-3040: ----------------------------------- What is your issue exactly? And please before you file JIRA with such vague description, try to discuss problem on forums / mailing lists first. > Missing modules > --------------- > > Key: WFLY-3040 > URL: https://issues.jboss.org/browse/WFLY-3040 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi > Affects Versions: 8.0.0.Final > Environment: Windows 64 bits > Reporter: David Cabillic > Assignee: Thomas Diesler > > I listed modules with links to missing ones : > || module || missing module || > | org.infinispan.client.hotrod | com.google.protobuf | > | org.jboss.as.aggregate | org.jboss.as.managed-beans | > | org.jboss.genericjms | org.jboss.genericjms.provider | -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3040) Missing modules

by David Cabillic (JIRA)

[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ] David Cabillic commented on WFLY-3040: -------------------------------------- Sorry, perhaps OSGi is not the good component, it is a Wildfly's modules issue. > Missing modules > --------------- > > Key: WFLY-3040 > URL: https://issues.jboss.org/browse/WFLY-3040 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: OSGi > Affects Versions: 8.0.0.Final > Environment: Windows 64 bits > Reporter: David Cabillic > Assignee: Thomas Diesler > > I listed modules with links to missing ones : > || module || missing module || > | org.infinispan.client.hotrod | com.google.protobuf | > | org.jboss.as.aggregate | org.jboss.as.managed-beans | > | org.jboss.genericjms | org.jboss.genericjms.provider | -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1800) OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1800?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz closed JGRP-1800. ------------------------------------- Resolution: Done The issue no longer appears in the test results. I'll reopen if it starts to appear again. > OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages > ------------------------------------------------------------------------------------------- > > Key: JGRP-1800 > URL: https://issues.jboss.org/browse/JGRP-1800 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL, Solairis > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > testRegularMessageSending is a kind of smoke test for the stack used in OverlappingMergeTest: > - three channels a,b,c are created with a particular stack (see modifyConfigs) > - each of a,b,c sends 5 multicast messages to the group, with message payloads "1", "2", "3", "4", "5" > - the receiver in each channel collects up the multicasts received > - the test checks that all 15 messages are received by each of the channels, and an assertion error is thrown is this is not the case > This test is failing occasionally. An example of the error: > {noformat} > Error Message > (C) num_mcasts=C: 1 C: 2 C: 3 C: 4 C: 5 A: 1 B: 1 A: 2 B: 2 B: 3 B: 4 A: 4 B: 5 A: 5 expected: 15) > Stacktrace > java.lang.AssertionError > at org.jgroups.tests.OverlappingMergeTest.checkReceivedMessages(OverlappingMergeTest.java:476) > at org.jgroups.tests.OverlappingMergeTest.testRegularMessageSending(OverlappingMergeTest.java:66) > {noformat} > This assertion error indicates that multicast #3 was not received from A by C. > This is a very simple scenario and failures should not be occurring. I mention this error as there are other merge tests, namely: > * testOverlappingMergeWithBC > * testOverlappingMergeWithABC > which are more complex, but when we look at their failures, they fail on an initial step similar to the one described above. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1800) OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1800?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1800: ------------------------------------------- I have reviewed the platform test results incorporating this change: - instances of the failure before the change (across all platforms): 18 - instances of this failure after the change (across all platforms): 0 So it appears that this was the root cause of the issue. I'm going to close this issue. > OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages > ------------------------------------------------------------------------------------------- > > Key: JGRP-1800 > URL: https://issues.jboss.org/browse/JGRP-1800 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL, Solairis > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > testRegularMessageSending is a kind of smoke test for the stack used in OverlappingMergeTest: > - three channels a,b,c are created with a particular stack (see modifyConfigs) > - each of a,b,c sends 5 multicast messages to the group, with message payloads "1", "2", "3", "4", "5" > - the receiver in each channel collects up the multicasts received > - the test checks that all 15 messages are received by each of the channels, and an assertion error is thrown is this is not the case > This test is failing occasionally. An example of the error: > {noformat} > Error Message > (C) num_mcasts=C: 1 C: 2 C: 3 C: 4 C: 5 A: 1 B: 1 A: 2 B: 2 B: 3 B: 4 A: 4 B: 5 A: 5 expected: 15) > Stacktrace > java.lang.AssertionError > at org.jgroups.tests.OverlappingMergeTest.checkReceivedMessages(OverlappingMergeTest.java:476) > at org.jgroups.tests.OverlappingMergeTest.testRegularMessageSending(OverlappingMergeTest.java:66) > {noformat} > This assertion error indicates that multicast #3 was not received from A by C. > This is a very simple scenario and failures should not be occurring. I mention this error as there are other merge tests, namely: > * testOverlappingMergeWithBC > * testOverlappingMergeWithABC > which are more complex, but when we look at their failures, they fail on an initial step similar to the one described above. -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1795: ------------------------------------------- I have reviewed the platform test results incorporating this change: instances of the failure before the change (across all platforms): 10 instances of this failure after the change (across all platforms): 0 So it appears that this was the root cause of the issue. I'm going to keep this open for another test run, just to confirm. > OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages > ----------------------------------------------------------------------- > > Key: JGRP-1795 > URL: https://issues.jboss.org/browse/JGRP-1795 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions. > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > This test does the following with two channels a and b: > - adds a DISCARD layer to a to disccard 50% of down messages > - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB > - wait 10 seconds for 20 messages to be received by each of a and b > - print out the messages received > - remove the DISCARD layer from a > - wait 2.5 seconds for further messages to arrive > - assert that 20 messages have arrived for each channel a and b > The test fails on the assertion, with results such as: > {noformat} > expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11] > {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

11 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2014