May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2060) Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-2060?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-2060: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1330729|https://bugzilla.redhat.com/show_bug.cgi?id=1330729] from MODIFIED to ON_QA > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2060 > URL: https://issues.jboss.org/browse/JGRP-2060 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.9 > Reporter: Brad Maxwell > Assignee: Bela Ban > Fix For: 3.6.10, 4.0 > > > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT error message "key server is currently not set" should be logged with debug level

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-2121: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1380657|https://bugzilla.redhat.com/show_bug.cgi?id=1380657] from MODIFIED to ON_QA > ASYM_ENCRYPT error message "key server is currently not set" should be logged with debug level > ---------------------------------------------------------------------------------------------- > > Key: JGRP-2121 > URL: https://issues.jboss.org/browse/JGRP-2121 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0 > Reporter: Vlado Pakan > Assignee: Vlado Pakan > Priority: Trivial > Fix For: 4.0 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2626) Network interface selection criteria is not working for a duplicate IP addresses but one is down

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2626?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2626: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1442325|https://bugzilla.redhat.com/show_bug.cgi?id=1442325] from MODIFIED to ON_QA > Network interface selection criteria is not working for a duplicate IP addresses but one is down > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-2626 > URL: https://issues.jboss.org/browse/WFCORE-2626 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: On Fedora 24 KVM instance, I added 2 extra NICs those are recognized as ens9 and ens10. Both have 192.168.1.1 but one is down. > {code} > # ip address show > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 > link/ether 52:54:00:ca:86:e2 brd ff:ff:ff:ff:ff:ff > inet 192.168.122.117/24 brd 192.168.122.255 scope global dynamic ens3 > valid_lft 3483sec preferred_lft 3483sec > inet6 fe80::782d:5d87:243d:917f/64 scope link > valid_lft forever preferred_lft forever > 3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 > link/ether 52:54:00:ee:c6:16 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.1/24 scope global ens9 > valid_lft forever preferred_lft forever > 4: ens10: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 > link/ether 52:54:00:52:78:ca brd ff:ff:ff:ff:ff:ff > inet 192.168.1.1/24 scope global ens10 > valid_lft forever preferred_lft forever > {code} > Reporter: Osamu Nagano > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta16 > > > In the standalone.xml, there are {{<up/>}} criterion which is sufficient to identify a unique NIC under the environment described above. > {code} > <interfaces> > <interface name="management"> > <up/> > <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> > </interface> > <interface name="public"> > <up/> > <inet-address value="${jboss.bind.address:127.0.0.1}"/> > </interface> > </interfaces> > {code} > But it says "ambiguous". WildFly 10.1.0.Final doesn't show this error. > {code} > # $JBOSS_HOME/bin/standalone.sh -b 192.168.1.1 -bmanagement=192.168.1.1 > ... > 04:38:52,839 WARN [org.jboss.as.controller] (MSC service thread 1-3) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity, > no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10]. > 04:38:52,840 WARN [org.jboss.as.controller] (MSC service thread 1-4) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity, > no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10]. > 04:38:52,840 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.network.public: org.jboss.msc.service.StartException in service jboss.network.public: WFLYSRV0082: failed to resolve interface public > at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > 04:38:52,841 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.network.management: org.jboss.msc.service.StartException in service jboss.network.management: WFLYSRV0082: failed to resolve interface management > at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-148) Support suppressed exceptions in log formatting

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-148?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-148: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1441890|https://bugzilla.redhat.com/show_bug.cgi?id=1441890] from MODIFIED to ON_QA > Support suppressed exceptions in log formatting > ----------------------------------------------- > > Key: LOGMGR-148 > URL: https://issues.jboss.org/browse/LOGMGR-148 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Reporter: David Lloyd > Assignee: James Perkins > Fix For: 1.5.7.Final > > > In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by. > This JIRA was created to track a back port of the JDK 7 enhancement to support suppressed exceptions to the 1.5.x branch which requires JDK 6. This will introduce a new requirement that the 1.5 branch will require JDK 7 to compile, but will still work on JDK 6. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8631) Integration test for WFCORE-2647 Add an option to always send the client SSL certificate to LDAP server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8631?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8631: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1327758|https://bugzilla.redhat.com/show_bug.cgi?id=1327758] from MODIFIED to ON_QA > Integration test for WFCORE-2647 Add an option to always send the client SSL certificate to LDAP server > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-8631 > URL: https://issues.jboss.org/browse/WFLY-8631 > Project: WildFly > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2647) Add an option to always send the client SSL certificate to LDAP server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2647?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2647: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1327758|https://bugzilla.redhat.com/show_bug.cgi?id=1327758] from MODIFIED to ON_QA > Add an option to always send the client SSL certificate to LDAP server > ---------------------------------------------------------------------- > > Key: WFCORE-2647 > URL: https://issues.jboss.org/browse/WFCORE-2647 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.0.0.Beta18 > > > This is the component issue for https://issues.jboss.org/browse/JBEAP-4439 and https://bugzilla.redhat.com/show_bug.cgi?id=1327758 > The present code in {{LdapConnectionManagerService}} was designed so that the client cert is sent to authenticate the search account but during the username / password verification step, the client cert is not sent. > The present objective is to add an option (that will default to the old behavior) to send the client password also during the username / password verification. > This includes (citing [~dlofthouse]): > * Implement management model based configuration and an implementation for the current version > * Port back to older versions using a system property. > * Forward port the system property to the current version for compatibility. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2678) LDAP credential is revealed when error occurs at startup

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2678?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2678: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1443122|https://bugzilla.redhat.com/show_bug.cgi?id=1443122] from MODIFIED to ON_QA > LDAP credential is revealed when error occurs at startup > -------------------------------------------------------- > > Key: WFCORE-2678 > URL: https://issues.jboss.org/browse/WFCORE-2678 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: - EAP 6.4.13 > Reporter: Hisanobu Okuda > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta16 > > > When an error occurs at startup, LDAP credential is shown in the log file. It should not appear. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1958) RequestCorrelator "channel is not connected" error during shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1958?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1958: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1399195|https://bugzilla.redhat.com/show_bug.cgi?id=1399195] from MODIFIED to ON_QA > RequestCorrelator "channel is not connected" error during shutdown > ------------------------------------------------------------------ > > Key: JGRP-1958 > URL: https://issues.jboss.org/browse/JGRP-1958 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.5 > > > Error logged during shutdown of a channel due to RequestCorrelator failing to send a reply: > ERROR [org.jgroups.protocols.UNICAST2] (OOB-17,shared=tcp) couldn't deliver OOB message [dst: server1/web, src: server2/web (4 headers), size=62 bytes, flags=OOB|DONT_BUNDLE|RSVP]: java.lang.IllegalStateException: channel is not connected > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:544) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] > [incoming JGroups message] > It appears to just be a timing issue between shutdown of the channel and RequestCorrelator processing the message, which triggers a response message. > It would be good to either avoid triggering the exception in the first place, or suppress the error log during shutdown. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2894) Authentication with context defined in outbound connection with non-http-remoting protocol always fails unless it is Elytron default

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2894?page=com.atlassian.jira.plugi... ] Farah Juma moved JBEAP-11258 to WFCORE-2894: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2894 (was: JBEAP-11258) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Remoting Security (was: Remoting) (was: Security) Affects Version/s: (was: 7.1.0.DR19) > Authentication with context defined in outbound connection with non-http-remoting protocol always fails unless it is Elytron default > ------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2894 > URL: https://issues.jboss.org/browse/WFCORE-2894 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > Labels: eap7.1-rfe-failure > > Attempting to authenticate with authentication context defined in remote outbound connection will always fail unless a correct Elytron default context is defined with following security output on client side server: > {code}13:10:45,693 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=http-remoting://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[scheme=http-remoting,host=127.0.0.1,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}] > 13:10:45,729 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[null], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=127.0.0.1,set-port=4447,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}] > 13:10:45,756 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=http-remoting://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[scheme=http-remoting,host=127.0.0.1,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}] > 13:10:45,758 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[null], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=127.0.0.1,set-port=4447,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}] > {code} > When a correct Elytron default context is defined, security output on client side server is the following: > {code}13:14:10,571 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=http-remoting://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[scheme=http-remoting,host=127.0.0.1,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}] > 13:14:10,602 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}] > 13:14:10,612 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=http-remoting://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[scheme=http-remoting,host=127.0.0.1,port=4447], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}] > 13:14:10,613 TRACE [org.wildfly.security] (default task-1) getAuthenticationConfiguration uri=remote://127.0.0.1:4447, protocolDefaultPort=-1, abstractType=ejb, abstractTypeAuthority=jboss, purpose=null, MatchRule=[], AuthenticationConfiguration=[AuthenticationConfiguration:principal=admin,set-host=127.0.0.1,set-protocol=remote,set-port=4447,credentials-present,providers-supplier=org.wildfly.security.util.ProviderUtil$1@220487eb,sasl-mechanism-selector=((!JBOSS-LOCAL-USER&&DIGEST-MD5)),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}] > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1204) RealmIdentity should have a three-argument version of getCredential()

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1204?page=com.atlassian.jira.plugin.s... ] David Lloyd reassigned ELY-1204: -------------------------------- Assignee: David Lloyd > RealmIdentity should have a three-argument version of getCredential() > --------------------------------------------------------------------- > > Key: ELY-1204 > URL: https://issues.jboss.org/browse/ELY-1204 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Server, Realms > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta49 > > > {quote} > I observe that there is no method overload for {{RealmIdentity#getCredential()}} which accepts an {{AlgorithmParameterSpec}} as the {{CredentialSource}} types do. This theoretically limits the range of selectivity of credentials that can be used by a mechanism; though things like salt or nonce are usually derived from the stored credential rather than the other way around, it is possible that there are other parameters which might have an impact on the selection of the appropriate credential (like realm name, as I think this issue is about). > An appropriate three-argument overload can be added to this interface as a {{default}} method. An additional {{applyToCredential}} method can also be added accordingly. An additional {{getCredentialAcquireSupport}} method should be added as well; though it could be {{default}}, the default implementation would be less than optimal as it would have to delegate to {{getCredential}} to function properly. > It might be a good idea to add this overload now while the compatibility impact would be minimal; in this case, the new {{getCredentialAcquireSupport}} method would not have to be {{default}} (instead, the two-argument form could be made {{default}} or removed completely in favor of the three-argument version). > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

5 years, 6 months

1
0
0 / 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017