July 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1053) ResourceAdapter instances not registered for inflow crash recovery

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1053?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1053: ------------------------------------------------ Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 980920|https://bugzilla.redhat.com/show_bug.cgi?id=980920] from NEW to ON_QA > ResourceAdapter instances not registered for inflow crash recovery > ------------------------------------------------------------------ > > Key: JBJCA-1053 > URL: https://issues.jboss.org/browse/JBJCA-1053 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.17.Final, 1.1.0.Beta5 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.18.Final, 1.1.0.CR1 > > > We need to register the ResourceAdapter instances for inflow crash recovery, since we can't depend on users of ResourceAdapterRepository does it -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1060) Document v$session.program in sample Oracle configuration

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1060?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1060. ------------------------------------ Fix Version/s: 1.1.0.CR2 Resolution: Done Philippe Marschall contributed the fix > Document v$session.program in sample Oracle configuration > --------------------------------------------------------- > > Key: JBJCA-1060 > URL: https://issues.jboss.org/browse/JBJCA-1060 > Project: IronJacamar > Issue Type: Feature Request > Components: Documentation > Reporter: Philippe Marschall > Priority: Minor > Labels: jdbc, oracle > Fix For: 1.1.0.CR2 > > > The Oracle JDBC driver (ojdbc) supports the v$session.program connection property. This allows DBAs to identify the application associated with a connection. This is completely optional but considered good practice. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1660) LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)

by Manuel Dominguez Sarmiento (JIRA)

[ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.... ] Manuel Dominguez Sarmiento commented on JGRP-1660: -------------------------------------------------- I can confirm that we've randomly seen this behaviour in our production servers, and the diagnosis was similar: threads hanged as a consequence of tryLock() usage. We found out from code inspection that we could avoid this by using tryLock(timeout) which was sufficient for our needs. Unfortunately we forgot to file the bug report then, so we cannot give any more details (we lost track of which JGroups version we were using, configuration, etc.) At the time we thought it might have been related to JGRP-1610 which apparently was solved in 3.3. However at the time we could not confirm this, since we had resorted to tryLock(timeout) by then. > LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock) > --------------------------------------------------------------------------------- > > Key: JGRP-1660 > URL: https://issues.jboss.org/browse/JGRP-1660 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.4, 3.3.3 > Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz > 6GB RAM > Windows 7 > JRE 1.6.31 > Reporter: Architect SoftWeb.ISD > Assignee: Bela Ban > Fix For: 3.3.4, 3.4 > > Attachments: lockservice_stability_testcase.jar > > > We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock. > Each thread works during some time. > After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock(). > Here is stack trace: > Thread [Thread-ClientImitation-1] (Suspended) > Object.wait(long) line: not available [native method] > Locking$ClientLock(Object).wait() line: 485 > Locking$ClientLock.acquireTryLock(long, boolean) line: 1010 > Locking$ClientLock.tryLock() line: 896 > CENTRAL_LOCK(Locking).down(Event) line: 152 > ProtocolStack.down(Event) line: 1025 > JChannel.down(Event) line: 718 > LockService$LockImpl.tryLock() line: 102 > LockServiceStabilityTestCase$ClientImitation.run() line: 167 > Thread.run() line: 662 -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1668) Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC}

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/WFLY-1668?page=com.atlassian.jira.plugin.... ] Peter Skopek reassigned WFLY-1668: ---------------------------------- Assignee: Peter Skopek (was: Anil Saldhana) > Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC} > ------------------------------------------------------------------------------------ > > Key: WFLY-1668 > URL: https://issues.jboss.org/browse/WFLY-1668 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.0.0.Alpha2 > Reporter: Josef Cacek > Assignee: Peter Skopek > > Mechanism to obtain passwords from external sources for login modules works only with option {EXT} - non-cached. New feature to cache passwords with command option {EXTC[:timeout]} doesn't work. > Problem is propably in LdapExtLoginModule method createLdapInitContext, that doesn't deal with commands that starts with "{EXTC" -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1668) Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC}

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1668?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1668: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 982539|https://bugzilla.redhat.com/show_bug.cgi?id=982539] from POST to ASSIGNED > Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC} > ------------------------------------------------------------------------------------ > > Key: WFLY-1668 > URL: https://issues.jboss.org/browse/WFLY-1668 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.0.0.Alpha2 > Reporter: Josef Cacek > Assignee: Anil Saldhana > > Mechanism to obtain passwords from external sources for login modules works only with option {EXT} - non-cached. New feature to cache passwords with command option {EXTC[:timeout]} doesn't work. > Problem is propably in LdapExtLoginModule method createLdapInitContext, that doesn't deal with commands that starts with "{EXTC" -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1722) Validation of method params is not internationalized

by Juergen Zimmermann (JIRA)

[ https://issues.jboss.org/browse/WFLY-1722?page=com.atlassian.jira.plugin.... ] Juergen Zimmermann updated WFLY-1722: ------------------------------------- Environment: (was: When a method of a JAX-RS resource class is invoked due to e.g. a GET or a POST request, then the method's parameters are validated via bean validation. However, the language of violation messages is always the default Locale, and not calculated using the header parameter accept-language, e.g. accept-language=de. http://beanvalidation.org/1.1/spec contains an example for a class LocaleSpecificMessageInterpolator so that validation happens with a dedicated locale.) > Validation of method params is not internationalized > ---------------------------------------------------- > > Key: WFLY-1722 > URL: https://issues.jboss.org/browse/WFLY-1722 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 8.0.0.Alpha3 > Reporter: Juergen Zimmermann > Assignee: Stuart Douglas > -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1722) Validation of method params is not internationalized

by Juergen Zimmermann (JIRA)

[ https://issues.jboss.org/browse/WFLY-1722?page=com.atlassian.jira.plugin.... ] Juergen Zimmermann updated WFLY-1722: ------------------------------------- Description: When a method of a JAX-RS resource class is invoked due to e.g. a GET or a POST request, then the method's parameters are validated via bean validation. However, the language of violation messages is always the default Locale, and not calculated using the header parameter accept-language, e.g. accept-language=de. http://beanvalidation.org/1.1/spec contains an example for a class LocaleSpecificMessageInterpolator so that validation happens with a dedicated locale. > Validation of method params is not internationalized > ---------------------------------------------------- > > Key: WFLY-1722 > URL: https://issues.jboss.org/browse/WFLY-1722 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 8.0.0.Alpha3 > Reporter: Juergen Zimmermann > Assignee: Stuart Douglas > > When a method of a JAX-RS resource class is invoked due to e.g. a GET or a POST request, then the method's parameters are validated via bean validation. > However, the language of violation messages is always the default Locale, and not calculated using the header parameter accept-language, e.g. accept-language=de. > http://beanvalidation.org/1.1/spec contains an example for a class LocaleSpecificMessageInterpolator so that validation happens with a dedicated locale. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1722) Validation of method params is not internationalized

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created WFLY-1722: ---------------------------------------- Summary: Validation of method params is not internationalized Key: WFLY-1722 URL: https://issues.jboss.org/browse/WFLY-1722 Project: WildFly Issue Type: Bug Components: REST Affects Versions: 8.0.0.Alpha3 Environment: When a method of a JAX-RS resource class is invoked due to e.g. a GET or a POST request, then the method's parameters are validated via bean validation. However, the language of violation messages is always the default Locale, and not calculated using the header parameter accept-language, e.g. accept-language=de. http://beanvalidation.org/1.1/spec contains an example for a class LocaleSpecificMessageInterpolator so that validation happens with a dedicated locale. Reporter: Juergen Zimmermann Assignee: Stuart Douglas -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (AS7-6072) Automate creating EAP 6.x public API Javadoc

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-6072?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka commented on AS7-6072: ----------------------------------- 3) Would be {code} scp javadocs.jar x86-014.build.bos.redhat.com:/mnt/redhat/devel/staging/JBEAP/JBEAP-$VERSION {code} But I am considering whether staging from this job is a good idea. > Automate creating EAP 6.x public API Javadoc > -------------------------------------------- > > Key: AS7-6072 > URL: https://issues.jboss.org/browse/AS7-6072 > Project: Application Server 7 > Issue Type: Enhancement > Components: Build System, Documentation > Affects Versions: 7.1.3.Final (EAP) > Reporter: Ondrej Zizka > Assignee: Ondrej Zizka > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > Docspace page: https://docspace.corp.redhat.com/docs/DOC-134981 > First attempt: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/EAP6-javadoc/ > What's needed: > * Blacklist of skipped .jar's (cause exceptions when generating) > * XSLT to put <include>'s to pom.xml > * XSLT to put <groups> to pom.xml > See also https://docspace.corp.redhat.com/docs/DOC-105009 (bottom) -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (AS7-6072) Automate creating EAP 6.x public API Javadoc

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-6072?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka commented on AS7-6072: ----------------------------------- Done 1) and 2). > Automate creating EAP 6.x public API Javadoc > -------------------------------------------- > > Key: AS7-6072 > URL: https://issues.jboss.org/browse/AS7-6072 > Project: Application Server 7 > Issue Type: Enhancement > Components: Build System, Documentation > Affects Versions: 7.1.3.Final (EAP) > Reporter: Ondrej Zizka > Assignee: Ondrej Zizka > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > Docspace page: https://docspace.corp.redhat.com/docs/DOC-134981 > First attempt: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/EAP6-javadoc/ > What's needed: > * Blacklist of skipped .jar's (cause exceptions when generating) > * XSLT to put <include>'s to pom.xml > * XSLT to put <groups> to pom.xml > See also https://docspace.corp.redhat.com/docs/DOC-105009 (bottom) -- 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, 12 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 July 2013