May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5294) [DMN Designer] Boxed Expressions - Decision Tables - Users need to remember to add quotes on strings

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-5294: --------------------------------------- Summary: [DMN Designer] Boxed Expressions - Decision Tables - Users need to remember to add quotes on strings Key: DROOLS-5294 URL: https://issues.redhat.com/browse/DROOLS-5294 Project: Drools Issue Type: Enhancement Components: DMN Editor Reporter: Guilherme Gomes Assignee: Guilherme Gomes Attachments: demo.png As I user, I would like that {{"}} would be automatically added to expressions that look like a string, on Decision Tables columns (string typed): !demo.png|width=600! Thus, when the text entry in the cell is not a valid variable in that context neither a valid expression, {{"}} s must be added. ⚠️ This issue depends on the FEEL parser running on the client-side. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4993) [DMN Designer] Code Completion - add keywords

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4993?page=com.atlassian.jira.plug... ] Guilherme Gomes reassigned DROOLS-4993: --------------------------------------- Assignee: Valentino Pellegrino (was: Guilherme Gomes) > [DMN Designer] Code Completion - add keywords > --------------------------------------------- > > Key: DROOLS-4993 > URL: https://issues.redhat.com/browse/DROOLS-4993 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Reporter: Donato Marrazzo > Assignee: Valentino Pellegrino > Priority: Major > Labels: dmn-designer > > Manage FEEL expression keywords: > * in > * or > * and > * between > * if ... then ... else ... > * for ... in ... return ... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4993) [DMN Designer] Code Completion - add keywords

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4993?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4993: ------------------------------------ Story Points: 3 (was: 2) > [DMN Designer] Code Completion - add keywords > --------------------------------------------- > > Key: DROOLS-4993 > URL: https://issues.redhat.com/browse/DROOLS-4993 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Reporter: Donato Marrazzo > Assignee: Valentino Pellegrino > Priority: Major > Labels: dmn-designer > > Manage FEEL expression keywords: > * in > * or > * and > * between > * if ... then ... else ... > * for ... in ... return ... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ] Richard Achmatowicz edited comment on WFLY-13132 at 5/4/20 11:49 AM: --------------------------------------------------------------------- I have now worked out how to set the initialProtocol variable on the initial session creation or on the first invocation, but it feels a bit unnatural. It also natutally leads to the idea of a preferred protocol which seems a bit complicated. It then occurred to me that there is a different way to solve this problem which may be more natural. If a client connects on the HTTP upgrade port 8080, send back client mapping entries which apply only for that port (e.g. localhost:8080); if a client connects on the legacy port 4447, send back client mappings which apply to that port (e.g. localhost:4447). Then the client is responsible for connecting to the appropriate port via configured connections in wildfly-config.xml or entries in PROVIDER_URL. This would depend upon a way to identify the origin of the invocation: via legacy Remoting port or HTTP Upgrade port. It would eliminate the need for a preferred protocol as a client could only be associated with one protocol. was (Author: rachmato): I have now worked out how to set the initialProtocol variable on the initial session creation or on the first invocation, but it feels a bit unnatural. It also natutally leads to the idea of a preferred protocol which seems a bit complicated. It then occurred to me that there is a different way to solve this problem which may be more natural. If a client connects on the HTTP upgrade port 8080, send back client mapping entries which apply only for that port (e.g. localhost:8080); if a client connects on the legacy port 4447, send back client mappings which apply to that port (e.g. localhost:4447). Then the client is responsible for connecting to the appropriate port via configured connections in wildfly-config.xml or entries in PROVIDER_URL. > Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client > ----------------------------------------------------------- > > Key: WFLY-13132 > URL: https://issues.redhat.com/browse/WFLY-13132 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Beta2 > Reporter: Joerg Baesner > Assignee: Richard Achmatowicz > Priority: Major > Labels: downstream_dependency > Attachments: playground.zip > > > h2. +Issue+ > h3. +General Client setup:+ > {code:java} > Properties p = new Properties(); > p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory"); > p.put(Context.PROVIDER_URL, {see below}); > p.put(Context.SECURITY_PRINCIPAL, USER); > p.put(Context.SECURITY_CREDENTIALS, PWD); > Context context = new InitialContext(p); > {code} > ---- > h3. +Standard server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="http-remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > ---- > h3. +Legacy server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > h2. +Conclusion+ > Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on WFLY-13132: -------------------------------------------- I have now worked out how to set the initialProtocol variable on the initial session creation or on the first invocation, but it feels a bit unnatural. It also natutally leads to the idea of a preferred protocol which seems a bit complicated. It then occurred to me that there is a different way to solve this problem which may be more natural. If a client connects on the HTTP upgrade port 8080, send back client mapping entries which apply only for that port (e.g. localhost:8080); if a client connects on the legacy port 4447, send back client mappings which apply to that port (e.g. localhost:4447). Then the client is responsible for connecting to the appropriate port via configured connections in wildfly-config.xml or entries in PROVIDER_URL. > Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client > ----------------------------------------------------------- > > Key: WFLY-13132 > URL: https://issues.redhat.com/browse/WFLY-13132 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Beta2 > Reporter: Joerg Baesner > Assignee: Richard Achmatowicz > Priority: Major > Labels: downstream_dependency > Attachments: playground.zip > > > h2. +Issue+ > h3. +General Client setup:+ > {code:java} > Properties p = new Properties(); > p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory"); > p.put(Context.PROVIDER_URL, {see below}); > p.put(Context.SECURITY_PRINCIPAL, USER); > p.put(Context.SECURITY_CREDENTIALS, PWD); > Context context = new InitialContext(p); > {code} > ---- > h3. +Standard server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="http-remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > ---- > h3. +Legacy server configuration:+ > {code:xml} > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > ... > <remote connector-ref="remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > ... > </subsystem> > ... > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"> > <properties> > <property name="SSL_ENABLED" value="false"/> > </properties> > </connector> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > {code} > h5. +invocation from remote client to server with:+ > * {{remote://localhost:4447}} > * {{remote+http://localhost:8080}} > h5. +Client side topology update always:+ > {noformat} > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1 > DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547 > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web > DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb > {noformat} > h2. +Conclusion+ > Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12722) Upgrade Infinispan to 10.1.x.Final

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12722?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12722: -------------------------------- Description: 10.0.0.Final: https://issues.redhat.com/projects/ISPN/versions/12332894 10.1.0.Final: https://issues.redhat.com/projects/ISPN/versions/12342474 10.1.1.Final: https://issues.redhat.com/projects/ISPN/versions/12344239 10.1.2.Final: https://issues.redhat.com/projects/ISPN/versions/12344558 10.1.3.Final: https://issues.redhat.com/projects/ISPN/versions/12344717 10.1.4.Final: https://issues.redhat.com/projects/ISPN/versions/12344975 10.1.5.Final: https://issues.redhat.com/projects/ISPN/versions/12345160 10.1.6.Final: https://issues.redhat.com/projects/ISPN/versions/12345252 10.1.7.Final: https://issues.redhat.com/projects/ISPN/versions/12345475 was: 10.0.0.Final: https://issues.redhat.com/projects/ISPN/versions/12332894 10.1.0.Final: https://issues.redhat.com/projects/ISPN/versions/12342474 10.1.1.Final: https://issues.redhat.com/projects/ISPN/versions/12344239 10.1.2.Final: https://issues.redhat.com/projects/ISPN/versions/12344558 10.1.3.Final: https://issues.redhat.com/projects/ISPN/versions/12344717 10.1.4.Final: https://issues.redhat.com/projects/ISPN/versions/12344975 > Upgrade Infinispan to 10.1.x.Final > ---------------------------------- > > Key: WFLY-12722 > URL: https://issues.redhat.com/browse/WFLY-12722 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 19.0.0.Beta2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > 10.0.0.Final: https://issues.redhat.com/projects/ISPN/versions/12332894 > 10.1.0.Final: https://issues.redhat.com/projects/ISPN/versions/12342474 > 10.1.1.Final: https://issues.redhat.com/projects/ISPN/versions/12344239 > 10.1.2.Final: https://issues.redhat.com/projects/ISPN/versions/12344558 > 10.1.3.Final: https://issues.redhat.com/projects/ISPN/versions/12344717 > 10.1.4.Final: https://issues.redhat.com/projects/ISPN/versions/12344975 > 10.1.5.Final: https://issues.redhat.com/projects/ISPN/versions/12345160 > 10.1.6.Final: https://issues.redhat.com/projects/ISPN/versions/12345252 > 10.1.7.Final: https://issues.redhat.com/projects/ISPN/versions/12345475 -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5293) can't create new user in the aplication

by Michael Biarnes Kiefer (Jira)

Michael Biarnes Kiefer created DROOLS-5293: ---------------------------------------------- Summary: can't create new user in the aplication Key: DROOLS-5293 URL: https://issues.redhat.com/browse/DROOLS-5293 Project: Drools Issue Type: Bug Reporter: Michael Biarnes Kiefer Assignee: Mario Fusco when deploying the [business-central.war|https://repository.jboss.org/nexus/content/groups/pu...] to a [Wildfly14|https://download.jboss.org/wildfly/14.0.1.Final/wildfly-14.0.1....] and create a user with ./add-user.sh (i.e. michael) and start the application you can login as user michael. When the user michael (added as user a) Management user or b) Application user) adds in the application a user X with a pwd Y this user can't login. Seems to wrok only for the very fist time you add a user with ./add-user. If you repeat this for adding more user this doesn't work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4989) JACCAuthzPropagationTestCase failures are intermittent on CI

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-4989?page=com.atlassian.jira.plugin... ] James Perkins commented on WFLY-4989: ------------------------------------- [~rchakrab] I don't really know the steps other than running the test suite. My assumption is at the time this was filed it was failing on CI so I submitted a PR to ignore the test so CI would stop failing. > JACCAuthzPropagationTestCase failures are intermittent on CI > ------------------------------------------------------------ > > Key: WFLY-4989 > URL: https://issues.redhat.com/browse/WFLY-4989 > Project: WildFly > Issue Type: Bug > Components: Security, Test Suite > Reporter: James Perkins > Priority: Major > Labels: testsuite_stability > > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF_PullReque... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13425) Upgrade smallrye-open-api to 1.2.3

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13425: ----------------------------------- Summary: Upgrade smallrye-open-api to 1.2.3 Key: WFLY-13425 URL: https://issues.redhat.com/browse/WFLY-13425 Project: WildFly Issue Type: Component Upgrade Components: MP OpenAPI Affects Versions: 19.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5292) add more MEM for business-central needed to the doc

by Michael Biarnes Kiefer (Jira)

Michael Biarnes Kiefer created DROOLS-5292: ---------------------------------------------- Summary: add more MEM for business-central needed to the doc Key: DROOLS-5292 URL: https://issues.redhat.com/browse/DROOLS-5292 Project: Drools Issue Type: Task Affects Versions: 7.36.0.Final Reporter: Michael Biarnes Kiefer Assignee: Mario Fusco When you deploy the [business-central.war|https://repository.jboss.org/nexus/content/groups/pu...] to a [wildfly14|https://download.jboss.org/wildfly/14.0.1.Final/wildfly-14.0.1....] you have to raise the mem (JAVA_OPTS) that the wildfly starts. If not you get an error: 5:30:25,580 WARN [org.jboss.msc.service] (MSC service thread 1-2) MSC000007: An internal service error has occurred while processing an operation on service jboss.deployment.unit."kie-wb.war".WeldStartService: java.lang.OutOfMemoryError: GC overhead limit exceeded This is not explained in ant doc - but should. Wildfly 14.0.1 starts with mem values that don't support the deployment of business-central -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020