June 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: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1059911|https://bugzilla.redhat.com/show_bug.cgi?id=1059911] from VERIFIED to CLOSED > @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 was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-834) org.jboss.as.cmp dependency added only to EJB subdeployments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-834?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-834: ---------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 924548|https://bugzilla.redhat.com/show_bug.cgi?id=924548] from VERIFIED to CLOSED > org.jboss.as.cmp dependency added only to EJB subdeployments > ------------------------------------------------------------ > > Key: WFLY-834 > URL: https://issues.jboss.org/browse/WFLY-834 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: James Livingston > Assignee: jaikiran pai > > The CMP code adds a module dependency on org.jboss.as.cmp if there are any CMP beans in it (via the CMP marker). > If the <ejb-class> refers to a class not in the EJB jar itself, such as in a library jar, this will result in the proxy being created in the EAR classloader and not being able to find JBoss' CmpProxy class. > The solution is to add the dependency to the top-level deployment so it is available in all sub-deployments, rather than the such the ejb subdeployment. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2333) Web deployment code assumes only a single ServletContainerInitializer is present in each jar

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2333?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2333: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1060740|https://bugzilla.redhat.com/show_bug.cgi?id=1060740] from VERIFIED to CLOSED > Web deployment code assumes only a single ServletContainerInitializer is present in each jar > -------------------------------------------------------------------------------------------- > > Key: WFLY-2333 > URL: https://issues.jboss.org/browse/WFLY-2333 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Beta1 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.CR1 > > Attachments: diycdemo.zip, hellomyfaces.zip > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2513) BDA ID contains absolute the path of the deployment location

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2513?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2513: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1029099|https://bugzilla.redhat.com/show_bug.cgi?id=1029099] from VERIFIED to CLOSED > BDA ID contains absolute the path of the deployment location > ------------------------------------------------------------ > > Key: WFLY-2513 > URL: https://issues.jboss.org/browse/WFLY-2513 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Beta1 > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Fix For: 8.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2746) Workaround for auditlog syslog Facility not being configurable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2746?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2746: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1052187|https://bugzilla.redhat.com/show_bug.cgi?id=1052187] from VERIFIED to CLOSED > Workaround for auditlog syslog Facility not being configurable > -------------------------------------------------------------- > > Key: WFLY-2746 > URL: https://issues.jboss.org/browse/WFLY-2746 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.CR1 > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 8.0.0.Final > > > Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2644) Java heap space exceeded looping connect/disconnect cycle

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2644: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from VERIFIED to CLOSED > Java heap space exceeded looping connect/disconnect cycle > --------------------------------------------------------- > > Key: WFLY-2644 > URL: https://issues.jboss.org/browse/WFLY-2644 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 8.0.0.Beta1 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 8.0.0.Final > > > CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should Not Fail for Non-existent User.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2660?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2660: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from VERIFIED to CLOSED > LDAP Group Loading - Should Not Fail for Non-existent User. > ----------------------------------------------------------- > > Key: WFLY-2660 > URL: https://issues.jboss.org/browse/WFLY-2660 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Final > > > Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP. > One example is local authentication where the user may not exist. > Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2623) Unable to change process-id mechanism from process-id-uuid to process-id-socket-binding on transaction

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2623?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2623: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1036739|https://bugzilla.redhat.com/show_bug.cgi?id=1036739] from VERIFIED to CLOSED > Unable to change process-id mechanism from process-id-uuid to process-id-socket-binding on transaction > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-2623 > URL: https://issues.jboss.org/browse/WFLY-2623 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: Amos Feng > Assignee: Hayk Hovsepyan > Labels: transaction > Fix For: 8.0.0.Final > > > https://bugzilla.redhat.com/show_bug.cgi?id=1036739 > process-id mechanism can not be changed from process-id-uuid to process-id-socket-binding. > The following ERROR occurred at JBoss start-up: > {noformat} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 44) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: "JBAS014746: process-id-uuid may not be null" > {noformat} > The root reason is it does not check the PROCESS_ID_UUID if defined when booting the coreEnvironment service in TransactionSubsytemAdd. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-102) Messages#getBundle() needs to be privileged

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plu... ] RH Bugzilla Integration commented on JBLOGGING-102: --------------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1080991|https://bugzilla.redhat.com/show_bug.cgi?id=1080991] from VERIFIED to CLOSED > Messages#getBundle() needs to be privileged > ------------------------------------------- > > Key: JBLOGGING-102 > URL: https://issues.jboss.org/browse/JBLOGGING-102 > Project: JBoss Logging > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.1.4.GA, 3.2.0.Beta1 > Reporter: Ivo Studensky > Assignee: James Perkins > Fix For: 3.1.3.GA, 3.2.0.Beta1 > > > It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3048: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from VERIFIED to CLOSED > "Local" authentication fails when LDAP is used for ManagementRealm > ------------------------------------------------------------------ > > Key: WFLY-3048 > URL: https://issues.jboss.org/browse/WFLY-3048 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Environment: Ubuntu 13.04, Xeon-based VPS > Reporter: Matt Jensen > Assignee: Darran Lofthouse > Fix For: 8.1.0.CR1, 8.1.0.Final > > > When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working. > I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows: > <security-realm name="ManagementRealm"> > <authentication> > <local default-user="$local" /> > <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false"> > ... > </ldap> > </authentication> > <authorization map-groups-to-roles="false"> > <ldap connection="..."> > ... > </ldap> > </authorization> > </security-realm> > I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command. > The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm. > If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password. > I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password. > The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up. > The documentation specifically mentions that <local/> should work along with <ldap/> here: > https://docs.jboss.org/author/display/WFLY8/Security+Realms -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 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 June 2014