November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2433) please tag 7.3 in community repository

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2433?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-2433. ----------------------------- Resolution: Rejected EAP codebase is part of different repository that only gets some backported fixes from upstream (wildfly/as7). as such we cannot tag it in upstream repository as code is not there. All EAP sources can be found at ftp://ftp.redhat.com/redhat/jbeap/ > please tag 7.3 in community repository > -------------------------------------- > > Key: WFLY-2433 > URL: https://issues.jboss.org/browse/WFLY-2433 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Tom Eicher > > According to JBoss dowload page, at EAP 6.2.0, there is a JBoss AS 7.3.0 release; however no such release can be found in as7 or wildfly repository. > Please tag the 7.3.0 in either repository, so as not to have the community completely out of the loop. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-317) Multiple issues with named consequences

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-317?page=com.atlassian.jira.plugin... ] Mario Fusco updated DROOLS-317: ------------------------------- Description: Named consequences have the following issues: - consequence name not set for MVEL (java ok) - branch update using wrong leftTuple in phreak - missing consequence names not detected at compile time - LogicTransformer doesn't process branches with or correctly - Conditional named consequence cannot be invoked after an eval - Conditional named consequence doesn't work with inherited rules was: Named consequences have the following issues: - consequence name not set for MVEL (java ok) - branch update using wrong leftTuple in phreak - missing consequence names not detected at compile time - LogicTransformer doesn't process branches with or correctly > Multiple issues with named consequences > --------------------------------------- > > Key: DROOLS-317 > URL: https://issues.jboss.org/browse/DROOLS-317 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > Named consequences have the following issues: > - consequence name not set for MVEL (java ok) > - branch update using wrong leftTuple in phreak > - missing consequence names not detected at compile time > - LogicTransformer doesn't process branches with or correctly > - Conditional named consequence cannot be invoked after an eval > - Conditional named consequence doesn't work with inherited rules -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2430) App with custom ContainerResponseFilter (JAX-RS) fails deploy

by Rudy De Busscher (JIRA)

[ https://issues.jboss.org/browse/WFLY-2430?page=com.atlassian.jira.plugin.... ] Rudy De Busscher commented on WFLY-2430: ---------------------------------------- Retried with Beta2-snapshot (build 766 from CI) - Unzipped - Started standalone - mvn clean package on exampleRest app - through management console deploy - Call URL -> Exception So no idea what I'm doing wrong. > App with custom ContainerResponseFilter (JAX-RS) fails deploy > ------------------------------------------------------------- > > Key: WFLY-2430 > URL: https://issues.jboss.org/browse/WFLY-2430 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: REST > Affects Versions: 8.0.0.Beta1 > Environment: Windows 7 > Reporter: Rudy De Busscher > Assignee: Stuart Douglas > Attachments: exampleRest.zip > > > Created a simple rest application with a ContainerResponseFilter. The deploy fails with a ClassNotFoundException of javax.ws.rs.container.ContainerResponseFilter. > See also https://community.jboss.org/message/844105 -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-1533: ------------------------------------ [~pangalz] your testcase covers a different issue, see also WELD-1542. > UT015005: Error invoking method requestDestroyed on listener class > ------------------------------------------------------------------- > > Key: WFLY-1533 > URL: https://issues.jboss.org/browse/WFLY-1533 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4 > Reporter: Juergen Zimmermann > Assignee: Jozef Hartinger > Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip, testcase-wildfly-1533.zip > > > I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace: > 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9 > at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29] > at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21] -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-2387: ------------------------------------ Assignee: Scott Marlow (was: Stuart Douglas) I have submitted a PR that fixes the Class Loader problem: https://github.com/wildfly/wildfly/pull/5400 It is not possible to inject the BeanManager, but injection of beans will fail because weld has not fully started yet. This is a JPA problem, it *must* create the listener lazily if weld injection is to work properly, as weld cannot fully start without JPA having already started. For the most obvious case of why this is required according to the spec it should be possible to inject the EntityManager into the listener. Obviously if the listener is being created before hibernate has finished starting there is absolutely no way we can accomplish this. > CDI injection in entity listeners failing > ----------------------------------------- > > Key: WFLY-2387 > URL: https://issues.jboss.org/browse/WFLY-2387 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld, Class Loading, JPA / Hibernate > Affects Versions: 8.0.0.Beta1 > Reporter: Emond Papegaaij > Assignee: Scott Marlow > Fix For: 8.0.0.CR1 > > > When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception: > {code} > 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25] > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3] > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75) > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128) > at org.jboss.weld.Container.instance(Container.java:65) > at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) > at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) > at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71) > at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150) > at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847) > at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846) > at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) > ... 8 more > {code} > I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2430) App with custom ContainerResponseFilter (JAX-RS) fails deploy

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2430?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-2430: -------------------------------------- Hmm, this app appears to work fine. I just went to http://localhost:8080/exampleRest-1.0/data/registration/hello and ended up with: Wrapped : Hello World And no exception. This is using the latest WF. > App with custom ContainerResponseFilter (JAX-RS) fails deploy > ------------------------------------------------------------- > > Key: WFLY-2430 > URL: https://issues.jboss.org/browse/WFLY-2430 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: REST > Affects Versions: 8.0.0.Beta1 > Environment: Windows 7 > Reporter: Rudy De Busscher > Assignee: Stuart Douglas > Attachments: exampleRest.zip > > > Created a simple rest application with a ContainerResponseFilter. The deploy fails with a ClassNotFoundException of javax.ws.rs.container.ContainerResponseFilter. > See also https://community.jboss.org/message/844105 -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2430) App with custom ContainerResponseFilter (JAX-RS) fails deploy

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2430?page=com.atlassian.jira.plugin.... ] Stuart Douglas closed WFLY-2430. -------------------------------- Resolution: Cannot Reproduce Bug This appears to have been fixed, probably by the recent Resteasy update. > App with custom ContainerResponseFilter (JAX-RS) fails deploy > ------------------------------------------------------------- > > Key: WFLY-2430 > URL: https://issues.jboss.org/browse/WFLY-2430 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: REST > Affects Versions: 8.0.0.Beta1 > Environment: Windows 7 > Reporter: Rudy De Busscher > Assignee: Stuart Douglas > Attachments: exampleRest.zip > > > Created a simple rest application with a ContainerResponseFilter. The deploy fails with a ClassNotFoundException of javax.ws.rs.container.ContainerResponseFilter. > See also https://community.jboss.org/message/844105 -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-318) JBDS6 and SOA tooling error in Drools project

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-318?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen moved JBDS-2633 to DROOLS-318: -------------------------------------------------- Project: Drools (was: Developer Studio (JBoss Developer Studio)) Key: DROOLS-318 (was: JBDS-2633) Workflow: GIT Pull Request workflow (was: CDW v1) Affects Version/s: (was: 6.0.0.GA) Component/s: (was: drools) (was: integration-platform) Security: Public (was: Public) > JBDS6 and SOA tooling error in Drools project > --------------------------------------------- > > Key: DROOLS-318 > URL: https://issues.jboss.org/browse/DROOLS-318 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: OSX 64 bit, java 7 > Reporter: Eric D. Schabell > Assignee: Kris Verlaenen > Priority: Minor > Attachments: JBDS6_rewards_errors.png > > > JBDS 6 with soa tooling installed from here: > http://download.jboss.org/jbosstools/updates/integration/juno/integration... > This project in JBDS 5 (mavenized project in projects directory) imported and no errors in Problem tab, but in JBDS 6 the soa tooling causes errors to appear in Problems tab. These errors do not effect project, as unit tests run, it points to something internal to parsing the bpmn2 files. Assuming internal to tooling. > https://github.com/eschabell/brms-rewards-demo (mavenized project is found in the projects/* dir) > Attaching error image. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-318) JBDS6 and SOA tooling error in Drools project

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-318?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on DROOLS-318: -------------------------------------------- Moved to Drools project. > JBDS6 and SOA tooling error in Drools project > --------------------------------------------- > > Key: DROOLS-318 > URL: https://issues.jboss.org/browse/DROOLS-318 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: OSX 64 bit, java 7 > Reporter: Eric D. Schabell > Assignee: Kris Verlaenen > Priority: Minor > Attachments: JBDS6_rewards_errors.png > > > JBDS 6 with soa tooling installed from here: > http://download.jboss.org/jbosstools/updates/integration/juno/integration... > This project in JBDS 5 (mavenized project in projects directory) imported and no errors in Problem tab, but in JBDS 6 the soa tooling causes errors to appear in Problems tab. These errors do not effect project, as unit tests run, it points to something internal to parsing the bpmn2 files. Assuming internal to tooling. > https://github.com/eschabell/brms-rewards-demo (mavenized project is found in the projects/* dir) > Attaching error image. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2317) Trying to remove a server group as a server-group-scoped role leaks information

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2317: ----------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784] from ON_QA to VERIFIED > Trying to remove a server group as a server-group-scoped role leaks information > ------------------------------------------------------------------------------- > > Key: WFLY-2317 > URL: https://issues.jboss.org/browse/WFLY-2317 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Ladislav Thon > Assignee: Brian Stansberry > Labels: rbac-filed-by-qa > Fix For: 8.0.0.CR1 > > > When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this: > {code} > [1] ./bin/domain.sh > [2] ./bin/jboss-cli.sh -c > /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group]) > /core-service=management/access=authorization/role-mapping=NewRole:add > /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user) > /core-service=management/access=authorization:write-attribute(name=provider, value=rbac) > exit > [1] ^C > ./bin/domain.sh > [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX > /server-group=other-server-group:read-resource > /server-group=other-server-group:remove > {code} > What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this: > {code} > { > "outcome" => "failed", > "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found", > "rolled-back" => true > } > {code} > However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message: > {code} > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""}, > "rolled-back" => true > } > {code} > I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists. -- 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

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013