March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4373) org.jboss.log4j.logmanager module requires java.sql module

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4373?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-4373: ---------------------------------- Summary: org.jboss.log4j.logmanager module requires java.sql module (was: org.jboss.logmanager module requires java.sql module) > org.jboss.log4j.logmanager module requires java.sql module > ---------------------------------------------------------- > > Key: WFCORE-4373 > URL: https://issues.jboss.org/browse/WFCORE-4373 > Project: WildFly Core > Issue Type: Bug > Components: Modules > Affects Versions: 8.0.0.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > > org.jboss.logmanager module requires java.sql module > {code} > Caused by: java.lang.ClassNotFoundException: java.sql.SQLException from [Module "org.jboss.log4j.logmanager" version 1.1.6.Final-redhat-00001 from local module loader @7d3a22a9 (finder: local module finder @1d082e88 (roots: /opt/jboss/modules,/opt/jboss/modules/system/layers/base))] > {code} > It looks like in EAP 6.4 java.* was visible to everything. In EAP 7.2 with JBoss Modules changes likely due to JDK 11 modular changes, it looks like java.* is no longer just visible and JBoss Modules has some internal modules such as java.sql which would be needed to see these classes. > Tattletale says that logmanager jar has this class org.apache.log4j.jdbc.JDBCAppender which uses java.sql.* , so we should add a dependency on java.sql (javax.sql.api exports java.sql , but javax.sql.api module is marked deprecated) > EAP 6.4 > {code} > <module xmlns="urn:jboss:module:1.1" name="org.jboss.log4j.logmanager"> > <resources> > <resource-root path="log4j-jboss-logmanager-1.1.4.Final-redhat-1.jar"/> >  > </resources> > <dependencies> > <module name="javax.api"/> > <module name="javax.mail.api" optional="true"/> > <module name="javax.jms.api" optional="true"/> > <module name="org.dom4j" optional="true"/> > <module name="org.jboss.logmanager"/> > <module name="org.jboss.modules"/> > </dependencies> > </module> > {code} > {code} > grep -r java.sql `f module.xml` > <nothing> > {code} > EAP 7.2: > {code} > <module name="org.jboss.log4j.logmanager" xmlns="urn:jboss:module:1.8"> > <properties> > <property name="jboss.api" value="private"/> > </properties> > <resources> > <resource-root path="log4j-jboss-logmanager-1.1.6.Final-redhat-00001.jar"/> > </resources> > <dependencies> >  > <module name="java.desktop"/> > <module name="java.logging"/> > <module name="java.xml"/> > <module name="javax.mail.api" optional="true"/> > <module name="javax.jms.api" optional="true"/> > <module name="org.dom4j" optional="true"/> > <module name="org.jboss.logmanager"/> > <module name="org.jboss.modules"/> > </dependencies> > </module> > {code} > {code} > grep -r java.sql `f module.xml` > ./modules/system/layers/base/sun/jdk/main/module.xml:  > ./modules/system/layers/base/org/wildfly/extension/elytron/main/module.xml: <module name="java.sql"/> > ./modules/system/layers/base/org/wildfly/security/elytron-private/main/module.xml: <module name="java.sql"/> > ./modules/system/layers/base/io/undertow/core/main/module.xml: <module name="java.sql"/> > ./modules/system/layers/base/javax/sql/api/main/module.xml: <module name="java.sql" export="true"/> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AG-111) Add a feature to remove connections older than a certain amount of time

by Luis Barreiro (Jira)

Luis Barreiro created AG-111: -------------------------------- Summary: Add a feature to remove connections older than a certain amount of time Key: AG-111 URL: https://issues.jboss.org/browse/AG-111 Project: Agroal Issue Type: Feature Request Components: pool Affects Versions: 1.4 Reporter: Luis Barreiro Assignee: Luis Barreiro The reason behind this feature is firewalls with strict connection timeouts (even if the connection is active). In order to prevent those connections from becoming invalid, they should be removed before the firewall timeout. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.

by Liz Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ] Liz Clayton commented on DROOLS-3731: ------------------------------------- [~karreiro][~manstis] Would you be able to tell me how much of this jira is not already covered by the pop-up solution presented in: https://issues.jboss.org/browse/DROOLS-3674 > DMN UX - More info overlaid on models. > -------------------------------------- > > Key: DROOLS-3731 > URL: https://issues.jboss.org/browse/DROOLS-3731 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Liz Clayton > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: download (1).png, download.png > > > As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression. > Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11854) Distributable session manager cannot detect immutable external classes

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11854?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-11854: -------------------------------- Summary: Distributable session manager cannot detect immutable external classes (was: Add mechanism to enumerate Immutable session attribute classes) > Distributable session manager cannot detect immutable external classes > ---------------------------------------------------------------------- > > Key: WFLY-11854 > URL: https://issues.jboss.org/browse/WFLY-11854 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Currently, WildFly's distributed web session manager detects classes annotated with @Immutable placed into the web session, optimizes calls so HttpSession.getAttribute(...) are not treated as cache writes. > However, users don't always have access to the classes to be able to annotate them, e.g. they come from a web framework, etc. > The proposal is to add a public SPI that users can implement that provides a web application with a set of classes that should be treated as immutable with respect to the distributed web session manager. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11854) Distributable session manager cannot detect immutable external classes

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11854?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-11854: -------------------------------- Issue Type: Bug (was: Feature Request) > Distributable session manager cannot detect immutable external classes > ---------------------------------------------------------------------- > > Key: WFLY-11854 > URL: https://issues.jboss.org/browse/WFLY-11854 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Currently, WildFly's distributed web session manager detects classes annotated with @Immutable placed into the web session, optimizes calls so HttpSession.getAttribute(...) are not treated as cache writes. > However, users don't always have access to the classes to be able to annotate them, e.g. they come from a web framework, etc. > The proposal is to add a public SPI that users can implement that provides a web application with a set of classes that should be treated as immutable with respect to the distributed web session manager. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11854) Add mechanism to enumerate Immutable session attribute classes

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-11854: ----------------------------------- Summary: Add mechanism to enumerate Immutable session attribute classes Key: WFLY-11854 URL: https://issues.jboss.org/browse/WFLY-11854 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 16.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Currently, WildFly's distributed web session manager detects classes annotated with @Immutable placed into the web session, optimizes calls so HttpSession.getAttribute(...) are not treated as cache writes. However, users don't always have access to the classes to be able to annotate them, e.g. they come from a web framework, etc. The proposal is to add a public SPI that users can implement that provides a web application with a set of classes that should be treated as immutable with respect to the distributed web session manager. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

by Joel DuBien (Jira)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Joel DuBien commented on WFLY-11007: ------------------------------------ Hello, I'm encountering this same issue running keycloak in openshift from the docker image: jboss/keycloak:master Has there been any progress on a solution? TYIA! > Using OpenShift generated certificates and client auth cause TLS errors > ----------------------------------------------------------------------- > > Key: WFLY-11007 > URL: https://issues.jboss.org/browse/WFLY-11007 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 13.0.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Stuart Douglas > Priority: Major > > h2. Summary > It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message. > h2. Explanation > I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. > I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful. > h2. Possible solution > Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too. > Links: > - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13 > - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88 > - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616 > - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo... > - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key... > - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11853) Journal compacting doesn't work with JDK 11

by Miroslav Novak (Jira)

Miroslav Novak created WFLY-11853: ------------------------------------- Summary: Journal compacting doesn't work with JDK 11 Key: WFLY-11853 URL: https://issues.jboss.org/browse/WFLY-11853 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 14.0.0.Final, 16.0.0.Final Environment: {noformat} java 11-ea 2018-09-25 Java(TM) SE Runtime Environment 18.9 (build 11-ea+21) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode) {noformat} Reporter: Miroslav Novak Assignee: ehsavoie Hugonnet Journal compacting doesn't work with Artemis 1.5 and JDK 11 It fails with following stack trace: {noformat} 12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77) at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388) at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175) at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312) at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282) at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255) at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217) at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520) at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060) at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: java.lang.IllegalArgumentException: duplicate or slice at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238) {noformat} This causes issues also in scenario with journal replication. {noformat} 13:09:32,133 WARN [org.apache.activemq.artemis.core.server] (Thread-173) AMQ222013: Error when trying to start replication: java.lang.RuntimeException: Error during compact, look at the logs at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.scheduleCompactAndBlock(JournalImpl.java:1428) at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:540) at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:166) at java.base/java.lang.Thread.run(Thread.java:834) {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11026) Journal compacting doesn't work with JDK 11

by Miroslav Novak (Jira)

[ https://issues.jboss.org/browse/WFLY-11026?page=com.atlassian.jira.plugin... ] Miroslav Novak updated WFLY-11026: ---------------------------------- Affects Version/s: 16.0.0.Final > Journal compacting doesn't work with JDK 11 > ------------------------------------------- > > Key: WFLY-11026 > URL: https://issues.jboss.org/browse/WFLY-11026 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 14.0.0.Final, 16.0.0.Final > Environment: {noformat} > java 11-ea 2018-09-25 > Java(TM) SE Runtime Environment 18.9 (build 11-ea+21) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode) > {noformat} > Reporter: Martin Styk > Assignee: ehsavoie Hugonnet > Priority: Critical > Labels: Java11, jdk10, jdk11 > > Journal compacting doesn't work with Artemis 1.5 and JDK 11 > It fails with following stack trace: > {noformat} > 12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77) > at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388) > at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175) > at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312) > at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282) > at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255) > at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217) > at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520) > at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060) > at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.lang.IllegalArgumentException: duplicate or slice > at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238) > {noformat} > This causes issues also in scenario with journal replication. > {noformat} > 13:09:32,133 WARN [org.apache.activemq.artemis.core.server] (Thread-173) AMQ222013: Error when trying to start replication: java.lang.RuntimeException: Error during compact, look at the logs > at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.scheduleCompactAndBlock(JournalImpl.java:1428) > at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:540) > at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:166) > at java.base/java.lang.Thread.run(Thread.java:834) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4374) security-manager minimum-set for MBeanServerPermission createMBeanServer not working but permissions.xml does

by Bartosz Spyrko-Śmietanko (Jira)

[ https://issues.jboss.org/browse/WFCORE-4374?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Śmietanko commented on WFCORE-4374: -------------------------------------------------- Test case: https://github.com/spyrkob/wildfly/commit/97a9b88e8ba6aeb031bb8f51d644dd5... > security-manager minimum-set for MBeanServerPermission createMBeanServer not working but permissions.xml does > ------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4374 > URL: https://issues.jboss.org/browse/WFCORE-4374 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Priority: Major > > When configuring a jdbc driver deployment jar with permissions.xml it I was able to resolve all of the needed permissions. But then when I remove the permissions.xml from the deployment and define the same permissions in the security-manager, it fails saying it requires the javax.management.MBeanServerPermission createMBeanServer even though it is defined in the subsystem. > {code} > 23:41:13,007 ERROR [stderr] (ServerService Thread Pool -- 81) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanServerPermission" "createMBeanServer")" in code source "(vfs:/Users/bmaxwell/Downloads/02291781/jboss-eap-7.3/standalone/deployments/createMBeanServer.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.createMBeanServer.jar" from Service Module Loader") > {code} > {code} > <minimum-set> > <permission class="javax.management.MBeanServerPermission" name="createMBeanServer"/> > </minimum-set> > {code} > If you put a permissions.xml in the deployment's META-INF with this below then it works fine. The other permissions I used for the jdbc driver seemed to work fine, it is just this one that seems inconsistent for some reason. > {code} > <?xml version="1.0" encoding="UTF-8"?> > <permissions xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee > http://xmlns.jcp.org/xml/ns/javaee/permissions_7.xsd" > version="7"> > <permission> > <class-name>javax.management.MBeanServerPermission</class-name> > <name>createMBeanServer</name> > </permission> > </permissions> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 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 March 2019